Ethereum's Glamsterdam Upgrade: Why Don't We Know What's In It Yet?

General
1

I’ve been trying to follow the Ethereum roadmap lately, and I have to admit—I’m confused. We’re supposedly getting the Glamsterdam upgrade in H1 2026, but every time I read about it, the feature set seems uncertain.

Here’s what I think I know:

  • Enshrined Proposer-Builder Separation (ePBS) is coming
  • Block-level Access Lists for parallel processing
  • Target of 10,000 TPS by end of year
  • Verkle Trees in the follow-up Hegotá upgrade

But then I saw Vitalik’s comment from February that the “rollup-centric roadmap no longer makes sense.” And the new Platform team announcement to unify L1 and L2. And meanwhile, L1 is already doing 20-30 TPS with sub-2 gwei fees.

My question: Is this a good thing or a bad thing?

On one hand, I appreciate that the core devs are being responsive to how things actually evolved. The L2 ecosystem didn’t decentralize as fast as expected (only 2 of 50+ L2s hit Stage 2), while L1 got way more efficient than anyone predicted in 2023.

On the other hand, as someone building on Ethereum, it’s genuinely hard to plan. Do I optimize for L1? Build for L2? Wait for Glamsterdam’s parallel processing? The moving target makes architectural decisions really difficult.

I remember when I first started learning about Ethereum’s roadmap—it all seemed so clear. The Merge, then the Surge (rollups), then the other upgrades. But now it feels like we’re in this in-between state where nobody’s quite sure what the “correct” architecture is anymore.

For other developers here: How are you handling this uncertainty? Are you just building and adapting as things change? Waiting for more clarity? Focusing on L2s despite the roadmap shift?

I’d love to hear how more experienced folks are thinking about this. Especially curious about the trade-off between “ship fast and iterate” vs “plan carefully and execute.” Ethereum seems to be leaning toward the former, but I wonder if that’s the right call for a platform with this much value locked in it.

Sources:

2

Emma, great question! Let me try to add some context from the L2 infrastructure side, because I think the roadmap shift actually makes a lot of sense when you look at the data.

What IS confirmed for Glamsterdam:

  1. Enshrined Proposer-Builder Separation (ePBS): This is huge for MEV mitigation and censorship resistance. Right now, block building is centralized because builders need specialized infrastructure. ePBS moves this to the protocol level, which is a big decentralization win.

  2. Block Access Lists: This is the first step toward parallel execution on L1. Instead of processing transactions sequentially, independent transactions can run simultaneously. Think of it like going from single-core to multi-core processing.

  3. Performance targets: The 10,000 TPS goal isn’t just theoretical. With parallel processing and the gas limit increases already planned, it’s actually achievable by end of 2026.

Why the roadmap changed:

You mentioned only 2 of 50+ L2s hit Stage 2 decentralization. That’s the key insight. Back in 2023, the assumption was:

  • L1 would stay at ~15 TPS
  • L2s would quickly decentralize
  • Users would migrate to rollups for cheaper transactions

What actually happened:

  • L1 hit 20-30 TPS with sub-2 gwei fees (thanks to blobs from Pectra)
  • L2 decentralization turned out WAY harder than expected
  • Most L2s still have training wheels (multisigs, centralized sequencers)

The new Platform team’s job is to make L1 and L2 work together better, not choose one or the other. L2s are evolving into specialized platforms (think gaming chains, DeFi chains) rather than just “cheaper Ethereum.”

For your planning question:

Honestly? I’d optimize for L1 unless you have a specific reason to be on a particular L2. Here’s why:

  • L1 is getting faster (Glamsterdam’s parallel processing)
  • L1 fees are already reasonable for many use cases
  • L1 has the strongest decentralization and security guarantees
  • L2 interoperability is still messy

If you need ultra-low latency or application-specific features, then a specialized L2 makes sense. But for general DeFi or infrastructure? L1 is looking really solid right now.

The “ship fast and iterate” approach feels risky, but remember Pectra deployed successfully in May 2025. The dev team has proven they can execute frequent upgrades safely. I think the new cadence is actually healthier than the old “bundle everything into one huge upgrade” model.

3

As someone who audits smart contracts for a living, I have mixed feelings about the “ship fast and iterate” approach that Ethereum seems to be adopting.

The good news:

Pectra proved that frequent upgrades CAN be done safely. The May 2025 deployment went smoothly, and we didn’t see the kind of chaos that happened with some earlier hard forks. The core dev team has clearly gotten better at coordination and testing.

The security concern:

But here’s what keeps me up at night: every protocol upgrade introduces new attack surfaces. When you’re moving fast, there’s less time for:

  • Independent security audits of the upgrade itself
  • Community review of EIPs
  • Ecosystem testing across different clients and configurations
  • Discovery of edge cases that only show up in production

With Glamsterdam, we’re talking about some pretty fundamental changes:

  1. ePBS: Changes how blocks are built and proposed. This affects MEV dynamics, which means new economic attack vectors.

  2. Parallel processing: This is HARD. You need to ensure state conflicts are handled correctly. One bug in access list validation could lead to consensus failures or even exploits.

What this means for developers:

Emma, to answer your question about planning: I’d say focus on writing defensive, upgrade-resilient contracts.

Some principles I follow:

  • Minimize dependencies on specific gas costs (they WILL change)
  • Don’t make assumptions about block timing
  • Use well-tested patterns and libraries
  • Have upgrade paths built into your architecture (proxies, migration scripts)

The uncertainty is frustrating, but it’s also not new. We dealt with London, we dealt with Shanghai, we dealt with Pectra. Each time we thought the gas model would break things, and each time we adapted.

My take on the roadmap:

I actually think Lisa’s point about L1 vs L2 is spot on. L2s added a ton of complexity, and many haven’t delivered on the decentralization promises. If L1 can scale to 10,000 TPS with reasonable fees, that simplifies the security model dramatically.

One chain to audit. One set of upgrade risks. One canonical state.

That said, I want to see the Glamsterdam testnet run for a LONG time before mainnet deployment. If they’re serious about shipping fast, they need to be equally serious about testing thoroughly first.

Test twice, deploy once—that’s my motto.

4

This conversation is fascinating from a product perspective. I’ve been thinking a lot about how these technical roadmap shifts affect the actual end users of our products.

The user impact nobody’s talking about:

When Emma asks “how do I plan my architecture,” she’s really asking “how do I build something users can rely on?” And that’s where the roadmap uncertainty gets really problematic.

Think about it from a user’s perspective:

  • They finally figured out how to bridge to an L2
  • They learned about gas fees and how to optimize transactions
  • They set up wallets for multiple chains

And now we’re potentially telling them “actually, you might not need all that complexity anymore because L1 is getting faster and cheaper.”

But here’s the optimistic view:

Maybe this is actually GOOD for users in the long run. Lisa’s point about L2s becoming specialized platforms is interesting. Instead of “use L2 because it’s cheaper,” it becomes:

  • Use gaming L2s for games (optimized for microtransactions)
  • Use DeFi L2s for trading (optimized for MEV protection)
  • Use L1 for security-critical stuff (maximum decentralization)

That’s actually a clearer value proposition than “rollups are just cheaper Ethereum.”

What I’m doing about it:

At my protocol, we’re taking a multi-chain approach but building for L1 first. Here’s why:

  1. User trust: L1 is the most credibly neutral option
  2. Simplicity: Easier onboarding story (“it’s just Ethereum”)
  3. Future-proof: If Glamsterdam delivers 10K TPS, we’re already there
  4. Hedge: If it doesn’t, we can always deploy to L2s later

The community governance angle:

One thing that concerns me is how these decisions are being made. The Platform team announcement was good, but I wonder how much input non-core-dev stakeholders have. When you’re managing a product with billions in TVL, maybe the community should have more structured input into upgrade priorities.

Sarah’s point about testing is crucial. If we’re shipping faster, we need MUCH better community testing frameworks. Maybe that’s where efforts should focus—not just shipping upgrades, but building the infrastructure for the community to validate them thoroughly.

My question for the group:

Do you think the Ethereum Foundation should slow down and get more explicit community buy-in for major changes? Or is the current “core devs decide, community adapts” model actually more efficient?

I lean toward more transparency and structured feedback loops, but I’m curious what builders think.

5

Coming at this from a cross-chain infrastructure angle, I think the Glamsterdam roadmap shift has some really interesting implications for interoperability.

The bridge operator’s perspective:

When Lisa mentioned that L2s are becoming specialized platforms rather than just “cheaper Ethereum,” that actually makes my job both easier and harder.

Easier because:

  • Clear use case separation means we can optimize bridges for specific flows
  • If L1 is the “settlement layer” and L2s are “application layers,” the architecture is clearer
  • Less competition between dozens of generic L2s means more predictable liquidity

Harder because:

  • We’re building bridge infrastructure during active roadmap changes
  • Gas cost assumptions keep shifting (which affects bridge economics)
  • Parallel processing on L1 might change how we batch cross-chain messages

What the Platform team announcement means:

Alex, to your governance question: The new Platform team is actually a huge deal for infrastructure providers like me.

Before this, there was no clear coordination between L1 and L2 development. You’d have:

  • Ethereum core devs working on L1
  • Separate teams at Optimism, Arbitrum, etc. working on L2s
  • No unified standard for how they should interact

The Platform team hopefully means:

  • Standardized L1-L2 messaging
  • Coordinated upgrade schedules
  • Better cross-layer composability

The 10K TPS question:

If L1 actually hits 10,000 TPS with Glamsterdam’s parallel processing, it changes the entire value proposition of bridges.

Right now, bridges exist partly because L1 is expensive and slow. If L1 becomes fast and cheap:

  • Do we still need dozens of L2s?
  • Do bridges become primarily about connecting to OTHER L1s (Solana, Cosmos, etc.)?
  • Does liquidity consolidate back to mainnet?

My prediction:

I think we’ll see a “barbell” strategy emerge:

  1. L1 Ethereum: High-value, security-critical applications
  2. Specialized L2s: Gaming, social, specific DeFi niches
  3. Bridges: Mostly connecting Ethereum to non-EVM chains

The middle tier of “generic cheaper Ethereum” L2s will struggle. Why use a centralized L2 with training wheels when L1 is reasonably priced?

What I’m watching for:

  • Testnet performance of parallel processing
  • Actual TPS numbers vs. theoretical claims
  • How the Platform team standardizes L1-L2 interop
  • Whether major L2s actually reach Stage 2 decentralization

Sarah’s call for long testnet periods is spot-on. The last thing we need is a consensus failure during a bridge transaction—that’s how funds get lost.