Glamsterdam’s big bet: ePBS, BAL and the free option fight
Ethereum’s Glamsterdam upgrade locks in enshrined Proposer-Builder Separation (ePBS) and Block Access Lists (BAL). New research highlights a builder free option that can hit liveness during volatility. Here is what changes for wallets, rollups, and traders, plus the guardrails to ship in 2025.

Breaking: ePBS and BAL are set to headline Glamsterdam
On October 1, 2025, the Ethereum Foundation’s core development update confirmed the two headliners for the Glamsterdam upgrade: enshrined Proposer Builder Separation and Block level Access Lists. That short sentence masks a big shift in how Ethereum will produce blocks and how users will feel them. The confirmation came in the Foundation’s monthly Checkpoint update, which also sketched a near term timeline as teams wrap up Fusaka and turn their focus to Glamsterdam’s test networks and interoperability work. EF Checkpoint for October 1, 2025.
The choices matter because both features touch the heart of the market for maximum extractable value, often shortened to MEV, and the way applications hit state. Enshrined Proposer Builder Separation, usually written ePBS, moves the separation between the validator who proposes the next block and the market of builders who assemble it from a voluntary sidecar into the protocol itself. Block level Access Lists, or BAL, require each block to declare the state it will touch before executing. Taken together, they promise safer competition in block building and clearer state access that can later support better parallel execution. For broader context on parallel execution and intents, see our Ethereum interop moment analysis.
This article translates those plumbing changes into user impact. What changes for wallets, rollups and traders. Who might win or lose. What guardrails can neutralize new risks. And how to be ready between now and 2026.
ePBS in plain language
Today, most validators rely on a sidecar market to get the best block. A relay collects bids from specialized builders who assemble transactions into a profitable block, then forwards the winning bid to the validator. Validators accept the bid because it increases rewards. The system is efficient but not fully embedded in the protocol, which means different relays have different rules and failure modes.
Enshrined Proposer Builder Separation pulls that process into the protocol. Think of it like formalizing a farmers’ market that already exists behind the grocery store. The vendor stalls become numbered and regulated. There is a clear schedule for when bids must arrive. Payment and settlement are handled by the town, not by handshake. This reduces trust assumptions and creates a more competitive, transparent marketplace for block building.
In practice, ePBS means the validator proposes the block header and selects a builder, while the builder commits to an execution payload and proves it on time. Because it is inside the protocol, client teams can set rules for timeouts, penalties, and how backup payloads are used. The goals are simple: make the block market safer, keep liveness high, and give users more predictable inclusion.
BAL in a nutshell
If ePBS is about how the block is assembled, BAL is about what the block plans to touch. A Block level Access List is a manifest of the accounts and storage slots a block expects to read or write. Imagine a shipping label that lists every bin the picker will open in the warehouse. The picker can still do the job even if items move, but the label helps optimize paths, measure costs, and detect weird behavior.
For developers, BAL promises clearer accounting of state access, which can inform pricing and, in time, unlock better parallel processing. For users, the immediate impact is indirect. You may not feel BAL on day one. But the chain can measure and charge more fairly for the real cost of touching state, which can reduce noisy neighbor effects and help wallets predict fees.
The new wrinkle: a builder’s free option on liveness
A fresh research paper released on September 29, 2025, formalizes a risk that has been discussed informally for months. Under ePBS, the builder committed to a payload may have a short window where they can decide to withhold the payload after seeing new information, turning the slot into an empty block. That is a free option. On average, the paper estimates it would be exercised in roughly 0.82 percent of blocks under an eight second window, but on high volatility days it could reach up to 6 percent, which is precisely when users most need reliable inclusion. The authors also show that shortening the window or imposing penalties can reduce the incentive to pull the ripcord. The free option problem of ePBS.
What does that mean in concrete terms. Imagine a builder has committed to a payload that includes a set of arbitrage trades based on centralized exchange prices. Seconds later, prices gap. The block they promised is suddenly loss making. If the protocol lets them refuse to deliver without a cost, they may choose to withhold, turning the slot empty. One empty slot is a hiccup. A cluster of empty slots during a market break is a liveness event users will notice. Orders do not settle, liquidation engines misfire or pause, bridges wait longer, and every trader widens slippage.
This risk does not mean ePBS is dangerous by design. It means the design gives builders a small time window where they can influence liveness, and the protocol must make that decision neutral or costly enough that the market rarely exercises the option. The good news is that the mitigations are direct.
What changes for wallets
- Inclusion confidence as a feature. Wallets will be able to surface preconfirmations that are backed by protocol rules rather than soft guarantees from a relay. A preconfirmation is a promise about inclusion at a specific slot with measurable failure consequences. This lets wallets show a countdown and a probability that is grounded in protocol timeouts and penalties.
- Orderflow routing grows up. With ePBS inside the protocol, wallets can route transactions to a diverse set of builders through standardized interfaces. Expect default policies that prefer builders with lower failure rates, transparent penalties, and clear preconfirmation support. In effect, wallets will compete on inclusion quality and slippage, not just on gas price estimation.
- Better fee and failure modeling. Because BAL clarifies state access, wallets can reason about fee risk for complex transactions. They can also guide users when a volatile period increases the probability that a slot could go empty. Instead of a vague warning, users may see a concrete message such as: your transaction is preconfirmed for slot N with a 99.5 percent probability given current network conditions.
What changes for rollups
- Cleaner anchoring and sequencing. Many rollups already align their batch posting with mainnet slots. ePBS gives them a clearer contract with builders for inclusion. Preconfirmations allow sequencers to accept or reject orders with stronger guarantees about when the L1 data anchor will land. That can reduce cross domain latency and improve safety margins for bridging. See how permissionless L2s are evolving in Arbitrum BoLD flips the switch.
- Rollup boost style relaying. Expect rollups to adopt relay infrastructure that resembles the builder marketplace on L1 but tuned for their own sequencing rules. This can include preconfirmation channels for large orders, default censorship resistance constraints, and fallback paths when the primary builder fails to deliver.
- Better failure modes. The free option risk at L1 translates into planning for an occasional empty slot. Robust rollups will treat an empty slot as a first class event with clear rules. For example, pause finality for one batch, raise fees to dampen mempool growth, and publish a failover batch that only contains essential system transactions.
What changes for DeFi traders
- Latency and price discovery shift. With ePBS, the path to a canonical block is more standardized. Good builders will compete on propagation and low failure rates. Traders will see more stable inclusion latencies in benign times and a clearer distribution of delays in volatile windows. Strategy code can adapt to these distributions rather than relying on relay specific quirks.
- New liveness aware risk controls. If a slot goes empty, timing based strategies can break. Traders should encode risk controls that condition on recent empty slot frequency. For instance, widen slippage only after an empty slot cluster or pause latency sensitive trades until preconfirmation reliability recovers.
- Better rebates in the long run. A healthy, competitive builder market with protocol guardrails should increase the share of value returned to originators. Wallets and aggregators that negotiate on users’ behalf can direct flow to builders who return more value and stay within reliability budgets.
Who wins and who loses
- Likely winners. Builders who specialize in cross domain data and have strong propagation. Wallets that invest in preconfirmation user experience and smart routing. Rollups that build failover playbooks tied to measured liveness. Validators who diversify their builder connections and adopt default fallback policies. For the broader consolidation trend, see our take on Ethereum consolidation trendlines.
- On the bubble. Mid tier builders who depend on volatile arbitrage without risk controls. They gain from standardization but lose if penalties make free options expensive and if wallets demote them for spotty preconfirmation reliability.
- Under pressure. Single relay dependency. ePBS reduces but does not eliminate central bottlenecks. Teams that rely on one relay or a single builder relationship will face operational risk when volatile periods hit.
The mitigation menu
The research and design space has converged on a few concrete guardrails. They can be shipped in combination.
- Shorter option windows. The value of the free option grows with the length of the delivery window. Shrinking the window from eight seconds toward two to four seconds reduces the chance that new information makes a payload unprofitable. The trade off is tighter propagation budgets for data availability. Teams should profile this on devnets with realistic gossip conditions, not just idealized lab nets.
- Direct penalties for non delivery. A modest, protocol level penalty turns the free option into a paid option. Pricing can be fixed at first and made adaptive later. The penalty should be large enough to dominate typical delta moves in a slot under normal volatility, yet small enough not to lock out new builders. The enforcement must be automatic, transparent, and verifiable.
- Preconfirmations with teeth. A standardized preconfirmation tells users this payload will land at slot N barring a reorg of depth one, or a severe network failure, and it spells out the maker of the promise and the penalty for breaking it. Wallets can surface this to users, and rollups can embed it in sequencing rules. Builders with consistent preconfirmation success can be rewarded with more orderflow.
- Backup payloads and soft landing. Proposers should maintain backup bids from secondary builders. If the winner fails to deliver, the proposer can fall back rather than accept an empty slot. This is a mechanical mitigation that reduces liveness pain without changing incentives.
- Relay and builder diversity targets. Client defaults should encourage proposers to maintain connections to multiple relays and builders. This lowers the chance that a single failure mode cascades into empty slots.
- Telemetry and circuit breakers. Protocol clients and relays should publish a common set of liveness metrics. When empty slot frequency crosses a threshold, clients can automatically increase preference for builders with higher delivery reliability or trigger stricter preconfirmation requirements for a short period.
Ship it, with guardrails
The accelerationist case for ePBS is pragmatic. Ethereum has already lived with a de facto proposer builder separation through off chain relays. Enshrining it brings safety and better incentives into the base protocol. The free option risk is real but measurable and manageable. The cleanest path is to ship ePBS with guardrails on day one rather than waiting for an ideal design in a lab.
Concretely, the case for shipping now looks like this.
- Start with a shorter delivery window that keeps propagation feasible under real network conditions, then lengthen only if empirical data shows no liveness harm.
- Add a modest non delivery penalty that can be adjusted by governance after observing market behavior, not by opaque coordination among private actors.
- Make preconfirmations a first class interface. Bake the fields into client APIs so wallets and rollups can depend on them and compare providers.
- Require client teams to implement backup payload fallbacks, with an on switch in defaults, so proposers do not need to be experts to avoid empty slots.
That set does not freeze innovation. It creates a safer baseline where experimentation with auction formats, user rebates, and shared sequencing can continue without imposing liveness externalities on users.
Q4 2025 to 2026 readiness checklist
Here is a concrete list of actions teams can start now. Treat it as a living document to review at each testnet milestone.
-
Wallet teams
- Integrate preconfirmation fields into the transaction lifecycle. Show the promised slot, the identity of the builder, and an expected failure rate based on public telemetry.
- Add routing policies that demote builders with poor delivery under volatility. Expose an advanced setting for users who opt into high risk strategies.
- Update fee estimation to account for BAL driven state costs, especially for complex multi contract transactions.
-
Rollup teams
- Align batch posting with L1 slot boundaries and codify behavior for empty L1 slots. Document how preconfirmations inform sequencing decisions.
- Stand up a rollup boost style relay that is vendor neutral. Support multiple builders and public telemetry of delivery reliability.
- Run chaos drills on devnet to simulate clusters of empty L1 slots and validate bridge, oracle, and liquidation safety margins.
-
DeFi protocols and traders
- Encode liveness aware risk controls. Pause latency sensitive strategies when empty slot frequency exceeds a threshold.
- Adjust oracle read strategies to handle longer than usual update gaps. Consider using median of multiple sources during volatile windows.
- For protocols, set time based parameters such as auction durations and liquidation grace periods with a buffer for occasional empty slots.
-
Validators and staking operators
- Upgrade clients for ePBS compatibility and configure multiple relay connections by default.
- Enable backup payload fallbacks. Monitor and alert on empty slot events and builder delivery failures.
- Document operator playbooks for volatile periods, including how to rotate relays and how to verify preconfirmation health.
-
Builders and relays
- Implement risk controls that hedge exposure during the delivery window. Price bids with the penalty in mind to avoid overexercising the option.
- Publish public telemetry on delivery reliability, preconfirmation success, and propagation latency. Treat it as a product surface.
- Participate in devnets that stress shorter delivery windows and penalties. Share results so client defaults can converge on safe settings.
-
Researchers and client teams
- Instrument devnets to measure the option’s value under realistic volatility with varying windows and penalties.
- Test BAL’s impact on state access costs for common DeFi transactions. Publish reports that wallets can use in fee models.
- Define a small set of standard preconfirmation schemas and failure reason codes so the whole stack speaks the same language.
The path forward
Ethereum’s move to enshrined Proposer Builder Separation and Block level Access Lists is the most important market structure change since the Merge. Users will not see new buttons in their wallets on day one, but they will feel steadier inclusion and clearer promises when it matters. The free option problem is a real design wrinkle, not a showstopper. The combination of shorter windows, calibrated penalties, strong preconfirmations, and backup payloads can keep liveness high even in volatile markets.
We should ship ePBS with those guardrails, then iterate in public with data. That approach lets the builder market compete on reliability and user value without exporting its tail risks to everyone else. Glamsterdam is a chance to rewire block building for the next cycle. The right mix of incentives and circuit breakers can turn a theoretical risk into a practical non issue and unlock a safer, more competitive era for users, rollups, and builders alike.