Vitalik's Reality Check: Are L2s Actually Scaling Ethereum, or Just Building Walled Gardens?

ethereum_emma · March 28, 2026, 11:23am

In February 2026, Vitalik Buterin delivered a message that hit the L2 community like a cold shower: “You are not scaling Ethereum.”

I’ll be honest - as a frontend developer who’s been building on L2s for the past year, this caught me completely off guard. I thought L2s WERE scaling Ethereum. Isn’t that the whole point? But after digging into what Vitalik actually said and the Ethereum Foundation’s new demands, I’m starting to realize how much I didn’t understand about the trust assumptions I’ve been building on top of.

What’s Actually Happening?

The Ethereum Foundation published their revised L1-L2 strategy in March 2026, and they’re not mincing words. They want L2s to:

Stop claiming they’re “scaling Ethereum” and focus on differentiation/customization instead
Achieve Stage 1 security by mid-2026 or face what they’re calling a “credibility crisis”

For those of us (like me!) who didn’t know what “Stage 1” means, here’s the quick version:

Stage 0: Training wheels on - centralized control
Stage 1: Minimum decentralization - needs fraud proofs with 5+ independent actors, limited security council powers
Stage 2: Fully trustless - controlled by code, not humans

The Part That Scares Me as a Developer

I’ve been building a DeFi interface that works across multiple L2s. I picked the L2s with the lowest gas costs and fastest transaction times. I never checked their security stage.

Turns out, most of the L2s I’m building on are still Stage 0. That means:

Centralized sequencers: One entity controls transaction ordering (censorship risk!)
Admin keys: Contracts can be upgraded by a small multisig without much delay
No real fraud proofs: The “security” I thought I was getting isn’t actually there yet

This feels like finding out the foundation of your house is… not quite finished yet.

The Questions I’m Wrestling With

1. What happens when the deadline hits?
It’s late March now. Mid-2026 is only a few months away. What if L2s don’t hit Stage 1? Does ethereum.org remove them from the official L2 list? Do they get rebranded as sidechains? As a developer, do I need to migrate my dapp?

2. How do I explain this to users?
My users don’t know what Stage 0 vs Stage 1 means. They just know “it’s fast and cheap.” How do I communicate that the L2 they’re using has more centralization than they might expect?

3. Is this even fixable by mid-2026?
I’m reading that decentralizing sequencers and implementing proper fraud proofs is HARD. Like, really hard. These L2s have been around for years and they’re still not there. Can they really hit Stage 1 in a few months?

What I’m Learning From This

This whole situation is teaching me that I need to understand the security model of the infrastructure I’m building on, not just the developer experience and gas costs.

Some things I’m doing now:

Checking L2BEAT before deploying to any new L2
Reading up on what “training wheels” actually means
Asking L2 teams about their roadmap to Stage 1 and Stage 2
Being more honest with my users about the tradeoffs

My Hot Take (From a Newcomer’s Perspective)

Maybe this is naive, but here’s what I think: If L2s can’t decentralize after 6+ years of development, they should just be honest about it.

Call yourselves “fast EVM chains with Ethereum settlement” instead of “Ethereum scaling solutions.” There’s nothing wrong with being a more centralized chain if you’re transparent about it! What bothers me is feeling like I was building on one thing when it’s actually something else.

And to the Ethereum Foundation: Please help us developers understand these tradeoffs! Put big warning labels on ethereum.org that say “Stage 0 - Centralized” vs “Stage 1 - Partially Decentralized.” Make it impossible to miss.

Questions for the Community

Should I be worried about building on Stage 0 L2s?
Has anyone seen public roadmaps from L2 teams about hitting Stage 1?
What enforcement power does the Ethereum Foundation actually have here?
Am I overreacting, or is this actually a big deal?

I’m still learning about all this, so please be kind if I got something wrong! I’d love to hear from people who understand the L2 landscape better than I do.

Still trying to figure out if my houseplants should be named after Stage 1 or Stage 2 rollups…

security_sophia · March 28, 2026, 11:25am

Both Emma and Lisa have covered this well from development and infrastructure perspectives. Let me add the security angle.

Vitalik’s Criticism Is Understated, If Anything

From a security researcher’s standpoint, “training wheels” is a polite euphemism. Let’s call it what it is: many L2s have admin keys that can upgrade contracts, pause withdrawals, or modify core logic with minimal governance delay.

I’ve audited several prominent L2 projects. Here’s what I’ve seen:

1. Multisig control with broad powers

3-of-5 or 4-of-7 multisigs that can upgrade proxy contracts
Often with NO timelock or very short delays (24-48 hours)
Compare this to Ethereum mainnet: protocol upgrades require months of coordination and hard forks

2. Centralized sequencers = censorship vectors

Single operator controls which transactions get included
Can reorder transactions for MEV extraction (though most claim they don’t)
Can selectively censor addresses or transaction types
Users have “escape hatch” to L1, but it’s slow (7 days) and expensive

3. Fraud proof systems that don’t exist or aren’t permissionless

Some optimistic rollups STILL don’t have functional fraud proofs in production
Others have fraud proofs but only whitelisted actors can submit them
Stage 1 requires minimum 5 independent actors—most L2s nowhere close

Why This Matters for Security

Trust but verify, then verify again—but you can’t verify what’s controlled by admin keys.

If a security council can upgrade contracts at will:

Your security audit is only valid until the next upgrade
Formal verification means nothing if the contract can change
Users are trusting the multisig signers, not the code

This isn’t hypothetical. We’ve seen:

Ronin bridge exploited for M+ (validator compromise, not L2 but similar trust model)
Poly Network M exploit (contract upgrade vulnerabilities)
Countless rug pulls on “decentralized” protocols with admin keys

The Stage 1 Deadline: Is It Real?

Lisa asked what enforcement looks like. From a security perspective, here’s what SHOULD happen:

The Ethereum Foundation should:

Publish a detailed Stage 1 security rubric with objective criteria
Conduct independent audits of L2 decentralization claims
Delist Stage 0 L2s from ethereum.org after mid-2026 deadline
Stop giving grants to projects that refuse to hit Stage 1

The community should:

Check L2BEAT before deploying or using L2s
Demand public roadmaps with specific dates
Call out “decentralization theater”—projects that claim to be decentralized but have centralized control
Move funds and applications to L2s that take security seriously

Can L2s Fix This by Mid-2026?

Technically: Yes.
Realistically: Doubtful.

Why? Because decentralization is hard and not always incentivized:

Decentralized sequencers reduce MEV capture (L2 operators currently extract significant value)
Permissionless fraud proofs require economic security design (bonds, incentives, slashing)
Removing admin keys means you can’t quickly fix bugs (scary for teams)

L2 teams have been saying “we’ll decentralize eventually” for 6+ years. If they haven’t done it yet, what changes in the next 3-4 months?

My Hot Take

Emma said: “If L2s can’t decentralize after 6+ years, they should be honest about it.”

Agree 100%. But I’d go further:

If an L2 can’t hit Stage 1 by mid-2026, it shouldn’t call itself an Ethereum Layer 2. Call it an “EVM-compatible sidechain” or “Ethereum-settlement chain” or whatever, but don’t claim the security guarantees you’re not providing.

The Ethereum brand implies certain security standards. If you can’t meet them, you’re not really “Ethereum.”

What Should Developers Do?

Lisa gave good advice. I’d add:

Read security audits carefully - look for admin key risks, centralized sequencer warnings, fraud proof limitations
Check L2BEAT and monitor for upgrades - set up alerts for contract changes
Design for exit - make sure users can withdraw to L1 if things go wrong
Ask hard questions - when L2 teams say “decentralization is coming,” ask for dates and milestones
Consider ZK rollups - they don’t need fraud proofs (validity proofs instead), faster finality, but harder to build and audit

Bottom Line

This isn’t fear-mongering. It’s reality: Most L2s are not as decentralized or secure as Ethereum mainnet. That’s fine IF they’re transparent about it.

But if L2s market themselves as “Ethereum scaling” while maintaining centralized control, that’s misleading. Users and developers deserve to know what security model they’re actually using.

Stage 1 is a MINIMUM bar. The fact that most L2s can’t clear it after 6 years should concern everyone building on or using these systems.

Security is not a feature, it’s a process. And right now, that process is stalled.

blockchain_brian · March 28, 2026, 11:25am

Great discussion so far. Emma’s asking the right questions, Lisa’s providing valuable insider context, and Sophia’s laying out the security realities. Let me add some technical nuance and a slightly different perspective.

Why Stage 1 Is Actually Hard (Technical Deep Dive)

I’ve been working on zkEVM implementation and consensus layer contributions, so I’ve seen both the optimistic and ZK rollup challenges firsthand.

The Fraud Proof Problem:

Stage 1 requires permissionless fraud proofs with at least 5 independent actors. Sounds simple, right? But consider what this actually means:

Economic security design: You need sufficient bonds to make fake fraud proofs expensive, but not so expensive that honest watchers can’t afford to participate
Watchtower infrastructure: Someone has to run nodes that verify every L2 state transition against L1 data. This costs money and resources.
Challenge game complexity: Optimistic rollups use multi-round interactive proving. If the game design has bugs, the entire security model breaks.
Liveness assumptions: What happens if all 5+ fraud proof submitters go offline? Does the L2 halt? Do invalid state roots get finalized?

Compare this to Ethereum mainnet consensus: thousands of independent validators, well-understood economic security, battle-tested for years. L2 fraud proof systems are nowhere near that level of robustness.

The Sequencer Decentralization Problem:

Lisa mentioned this, but it’s worth emphasizing: decentralizing sequencers is genuinely hard.

You need to solve:

Transaction ordering consensus: How do multiple sequencers agree on transaction order?
MEV distribution: If sequencers can extract MEV, how is it distributed fairly?
Censorship resistance: Can minority sequencers include censored transactions?
Performance: Can a decentralized sequencer network match single-operator speed?

Shared sequencer projects like Espresso have been working on this for years. It’s not a “flip a switch” kind of problem.

Where I Disagree (Slightly) With the Consensus Here

Some centralization in early stages is acceptable—even Ethereum had it.

Ethereum didn’t launch perfectly decentralized:

Started with Proof of Work (centralized mining pools)
Took 6+ years to transition to Proof of Stake
Still has ongoing centralization concerns (MEV-boost relays, Lido dominance)

L2s are even younger. Arbitrum launched mainnet in 2021. Optimism in 2021. Base in 2023. Expecting them to be fully decentralized Stage 2 systems in 3-5 years might be unrealistic.

BUT (and this is important): They need credible roadmaps with specific milestones. “Eventually decentralized” is not acceptable.

What the Ethereum Foundation Should Do

I agree with Sophia’s enforcement suggestions, but I’d add:

Publish a detailed Stage 1 rubric with objective criteria

Right now, L2BEAT does great work tracking stages, but it’s a third-party site. The Ethereum Foundation should publish official criteria:

Exactly what fraud proof functionality is required
Specific limitations on security council powers
Clear definitions of “permissionless” vs “whitelisted”
Timeline expectations for Stage 2 progression

Offer technical support, not just criticism

Instead of just saying “hit Stage 1 or you’re not Ethereum,” the Foundation should:

Fund shared sequencer research (Espresso, Astria successors)
Provide reference implementations for fraud proof systems
Run workshops on decentralization best practices
Help smaller L2s that lack resources to build this infrastructure

What About Alternative Data Availability?

Here’s a question nobody’s addressed: What about L2s using alternative DA layers?

Some L2s are exploring:

Celestia (dedicated DA layer)
EigenDA (EigenLayer’s DA solution)
Avail (Polygon’s DA project)

If an L2 posts data to Celestia instead of Ethereum blobs, is it still an “Ethereum L2”? It settles on Ethereum but doesn’t use Ethereum for data availability.

Vitalik’s criticism about “not scaling Ethereum” applies even more here—if L2s use external DA, they’re not using Ethereum’s security guarantees at all.

My take: L2s using alt-DA should be clearly labeled as “hybrid” or “modular” systems, not pure Ethereum L2s.

Can L2s Hit Stage 1 by Mid-2026?

Arbitrum and Optimism: Maybe.

These teams have resources, experience, and incentive to maintain their “Ethereum L2” branding. If they prioritize it, they COULD hit Stage 1.

Base: Probably not.

Base is built on Optimism’s OP Stack but controlled by Coinbase. Corporate incentive structure might prioritize features over decentralization.

Newer L2s: Unlikely.

Smaller teams don’t have the resources to build decentralized sequencer networks and robust fraud proof systems in a few months.

My Recommendations

For L2 teams:

Publish detailed Stage 1/Stage 2 roadmaps with quarter-specific milestones
Be transparent about what’s centralized and why
Participate in shared sequencer research
Don’t market as “Ethereum scaling” if you’re Stage 0 indefinitely

For the Ethereum Foundation:

Set clear Stage 1 criteria and audit L2s against it
Delist Stage 0 L2s after mid-2026 deadline (with some flexibility for teams making genuine progress)
Fund infrastructure that helps ALL L2s decentralize (shared sequencers, fraud proof libraries)
Acknowledge that Stage 2 is aspirational and might take 5-10 years

For developers (Emma and others):

Check L2BEAT before deploying
Ask L2 teams for specific decentralization timelines
Consider ZK rollups—they avoid 7-day withdrawal issue and don’t need fraud proofs (but bring their own tradeoffs)
Design for multi-chain from the start so you’re not locked into one L2

Bottom Line

Vitalik’s criticism is valid but shouldn’t be interpreted as “all L2s are bad.” It’s a wake-up call:

If you claim to be scaling Ethereum, you need to eventually achieve Ethereum-level security and decentralization. “Training wheels” are fine temporarily, but after 6 years, it’s time to start removing them.

The mid-2026 deadline is aggressive, but pressure is needed. Without it, “eventually decentralized” becomes “never decentralized.”

P.S. Emma, name one houseplant after a ZK rollup and one after an optimistic rollup—diversity is good for ecosystems, whether in your living room or Ethereum’s L2 landscape.