Enshrined PBS: Exclusive, Effortless Builder-Proposer Split

Enshrined PBS brings the builder–proposer split into the Ethereum protocol itself. The goal is simple: make block building fair, private, and reliable without external relays or side agreements. “Exclusive” refers to guaranteed private orderflow routes; “effortless” means node operators get this by default with minimal setup.

This approach aims to reduce censorship risks, cut trust in third parties, and keep returns for stakers consistent. It also offers users more predictable inclusion, even if builders compete for orderflow.

What Enshrined PBS means

Today, most validators rely on MEV-Boost relays. These relays connect block builders with proposers but sit outside the protocol. Enshrined PBS replaces that off-chain trust with in-protocol rules that govern who can build, how bids work, and what gets included.

Builders assemble blocks. Proposers choose the highest-paying valid block. Enshrining the split means the chain enforces the auction, protects transaction data until reveal, and holds builders and proposers to their commitments.

Why Ethereum cares

MEV is real and large. Without safeguards, it invites censorship, spam, and opaque deals. When private relays control flow, a relay outage can stall a big share of blocks. Private orderflow markets also fragment liquidity and make inclusion uncertain.

Enshrined PBS aims to keep the auction open, make censorship visible, and give all participants clear incentives. It reduces the need for trust in specific relays or orderflow brokers.

How ePBS changes the flow

The block path shifts from off-chain relay rules to protocol rules. Below is a straightforward view of the lifecycle under a typical ePBS design.

1. Users submit transactions (public mempool or private routes).
2. Builders construct candidate blocks and post sealed bids to the proposer.
3. The protocol verifies bid commitments and enforces deadlines.
4. The proposer selects the highest valid bid with required contents.
5. The builder reveals the block body; the network verifies it matches the commitment.
6. If the reveal fails or is late, a fallback block gets used and penalties apply.

This path reduces the chance that a single off-chain relay or handshake blocks the best bid. It also gives the protocol a clear way to punish failed reveals and missed commitments.

Exclusive orderflow: pros and limits

Exclusive orderflow gives a builder private access to certain transactions for a short window. It can boost execution quality but can also reduce competition. The protocol must set a balance.

• Pros: better price improvement on swaps, lower failed-arb spam, tighter quotes for latency-sensitive trades.
• Pros: fewer leaked strategies, less sandwich exposure when privacy is strong.
• Limits: too much exclusivity shrinks competition and may cut proposer revenue.
• Limits: users need a clear path to inclusion even if a private lane fails.

A healthy design lets exclusive lanes exist but requires fallbacks. Inclusion rules and timed windows can keep the market open while preserving privacy benefits.

Effortless for stakers and users

“Effortless” means default safety with little configuration. A solo staker should not juggle relays or sign opaque terms. A user should not learn three new tools to get a fair fill.

• Default on: clients ship with ePBS enabled and sane network presets.
• One switch: opt into or out of private lanes without custom scripts.
• Automatic fallbacks: if a builder fails, the proposer has a ready public block.
• Clear metrics: clients expose bids won, reveals failed, and inclusion delays.

Small example: a home staker updates their client and restarts. The node now accepts sealed bids from many builders. It picks the best one and publishes metrics, all without an extra process or third-party API key.

Core pieces proposed for enshrined PBS

Researchers have outlined several building blocks. Each piece targets a known pain point: censorship, trust in relays, and non-delivery of bids.

Each component can ship in steps. A chain may start with blinded auctions and simple inclusion lists, then add stricter penalties and better privacy once clients mature.

How it compares with MEV-Boost today

MEV-Boost unlocked big rewards but relies on relays. Relays can censor, fail closed, or pick favorites. ePBS moves those rules on-chain, trims the trusted set, and standardizes penalties for missed delivery.

Practical example: a relay outage during a high-volatility hour. Under MEV-Boost, many proposers lose access to top bids and produce low-value blocks. With ePBS, multiple builders still post sealed bids directly through protocol messages; the proposer sees the commitments and selects the top one without a relay in the middle.

What “exclusive” should mean in practice

Exclusivity should serve execution quality, not entrench power. A fair model grants short exclusivity for private flow with strict deadlines, then requires public inclusion.

• Short window: a builder gets a few seconds to use a private bundle for price improvement.
• Inclusion duty: after the window, the same trades must be includable via the public path.
• Auditability: the chain records when a builder or proposer blocks a valid list item.

Picture a DEX trader posting a protected swap. The builder gets a brief private slot, fills at a better price, and reveals the block. If the builder fails, the swap moves to the fallback block via the inclusion list. The user sees either the improved fill or a timely public inclusion.

Risks and open questions

Design choices still carry trade-offs. Being clear on them helps set realistic expectations and keeps the roadmap focused.

• Market power: large builders could dominate unless entry costs stay low.
• Privacy vs. verification: stronger privacy can make enforcement harder.
• Latency games: tight deadlines may favor fast regions unless tuned well.
• DoS surfaces: open registration can attract spam; rate limits and fees help.
• Client diversity: all major clients must implement ePBS features without regressions.

Mitigations include simple, public rules; small, well-audited code paths; and gradual rollout with metrics on inclusion and revenue dispersion.

How to prepare as a builder or staker

You can make small moves now that pay off once ePBS lands. Focus on clean ops and measurable reliability.

1. Track metrics: log missed bids, reveal latencies, and block value vs. baseline.
2. Harden networking: diversify peers and use redundant paths for bid traffic.
3. Test fallbacks: keep a fast local block template ready at all times.
4. Simplify keys: isolate builder and proposer keys; automate rotations.
5. Stay current: follow client releases and ePBS testnet notes.

Small shop example: a two-person validator outfit sets alerts for reveal failures, adds an extra uplink, and rehearses a client rollback. The next time a dependency breaks, they still produce solid blocks.

What to watch next

Progress will come in phases. Expect testnets that trial blinded auctions, inclusion lists, and penalties under different latency assumptions.

• Client releases that add ePBS flags behind feature gates.
• Research notes on inclusion list formats and exceptions.
• Economic studies on revenue spread with and without exclusivity windows.
• Public dashboards that track censorship rates and failed reveals.

The aim is a protocol-level builder–proposer split that delivers private, fair execution with clear fallbacks. Done right, enshrined PBS makes exclusive orderflow safe and makes the experience effortless for stakers and users alike.