Vitalik Says L2s 'No Longer Make Sense'—Is He Right, or Is This Just Growing Pains?

General
1

I’ve been following the discussion around Vitalik’s Feb 3 statement about L2s, and as someone who builds on both L1 and L2s every day, I wanted to share some thoughts and hear what everyone else thinks.

What Happened?

In early February, Vitalik said something pretty shocking: “The original vision of L2s and their role in Ethereum no longer makes sense.” He gave two main reasons:

First, L2s have decentralized way slower than expected. Most are still at “Stage 0” with centralized sequencers and multisig bridges. Vitalik was blunt: “If you create a 10,000 TPS EVM where its connection to L1 is mediated by a multisig bridge, then you are not scaling Ethereum.”

Second, L1 itself is scaling now. The Pectra and Fusaka upgrades doubled blob throughput, raised the gas limit from 30M to 60M, and brought PeerDAS to mainnet. Ethereum L1 can now handle 50-100 TPS on its own.

My Experience as a Developer

Honestly, I’m conflicted about this. On one hand, I get the frustration with L2 centralization. When I audit smart contracts on some L2s, I see admin keys everywhere—upgrade functions, emergency pause buttons, centralized sequencers. That’s not the decentralization promise we signed up for.

On the other hand, from a practical dev perspective, L2s still feel essential. Even with the 60M gas limit, I’ve seen L1 gas spike during NFT mints or DeFi volatility. For most consumer apps—especially ones targeting regular people who aren’t crypto-native—L2 transaction costs are still way more predictable and affordable.

The Tooling Is Actually Good Now

Here’s something I don’t see mentioned enough: L2 developer tooling has gotten really mature. Cross-chain bridges (despite security concerns) work reasonably well. Frameworks like wagmi and ethers.js have solid L2 support. Users can onboard to L2s without understanding the underlying complexity.

If we pivot back to L1-first development, we’re not just abandoning infrastructure—we’re abandoning the tooling ecosystem that’s been built around it. That feels wasteful.

Questions I’m Wrestling With

What happens to existing L2 projects? I work on a DeFi protocol that’s already deployed on three different L2s. Are we supposed to migrate everything back to mainnet? That’s months of work, audits, liquidity migration…

Can L1 really handle everything? Even at 60M gas and improved blob throughput, can mainnet support the transaction volume of dozens of consumer apps running simultaneously? I’m skeptical.

Is this about trust or performance? If the issue is centralization (trust), that’s fixable over time. If it’s about L1 being “good enough” now (performance), that’s a different calculation.

I Think We Need Both

My tentative view: we need both L1 and L2s, but with clearer specialization. L1 for high-value, security-critical stuff. L2s for high-volume, application-specific workloads. Better interoperability so fragmentation isn’t a UX nightmare.

But I’m still learning and definitely don’t have all the answers. What do you all think? Is Vitalik right to question the L2-centric roadmap, or is this just growing pains before things get better?

I’d especially love to hear from:

  • Other developers building on L2s
  • Anyone working on L2 decentralization/sequencer networks
  • Users who actually rely on L2s for everyday transactions

Let’s figure this out together.

2

Emma, thank you for starting this thread—your developer perspective is exactly what we need in this discussion.

I want to respond specifically to your question: “Is this about trust or performance?” As someone who’s been building L2 infrastructure for six years, I think it’s both, and that’s why this is so complicated.

The Trust Problem Is Structural

You mentioned seeing admin keys everywhere when auditing L2 contracts. That’s not accidental—it’s by design for most current L2s. The dirty secret is that achieving Stage 2 decentralization (no training wheels) is incredibly hard, and some teams have explicitly chosen not to pursue it.

I recently spoke with an L2 team that told me they may never go beyond Stage 1 because their institutional customers’ compliance requirements demand ultimate control. Think about that: they’re choosing centralization to satisfy regulators. At that point, are we building blockchain infrastructure or just distributed databases with marketing?

The performance question is simpler but equally important. You’re right that even at 60M gas limit, L1 can spike during high demand. But here’s what’s changed: those spikes are now the exception, not the rule. For 80% of use cases, L1 is now “good enough” in terms of throughput and cost.

Where L2s Still Make Sense

That said, I agree with your conclusion that we need both. Here’s where I think L2s remain essential:

1. Specialized execution environments: Gaming applications that need sub-second finality. DeFi protocols requiring MEV protection. Privacy-focused apps using zkProofs for more than just compression.

2. Experimentation space: L2s can test new VM designs, novel consensus mechanisms, or experimental cryptography without risking L1 stability.

3. Application-specific optimization: A gaming L2 can optimize for different trade-offs than a financial L2. That specialization has value.

The Migration Question Is Real

Your point about migration is something I’ve been thinking about constantly. We have entire ecosystems built on current L2s—billions in TVL, thousands of deployed contracts, established user bases. You can’t just hand-wave that away with “move back to L1.”

But I also think Vitalik’s critique forces a necessary reckoning. If your L2 is just a faster, cheaper Ethereum with a multisig bridge and centralized sequencer, you’re not contributing to Ethereum’s decentralization—you’re fragmenting it.

What I Think Should Happen

Short term: L2 teams need to publish realistic decentralization roadmaps with actual milestones, not “we’ll get to it eventually.” Stage 1 by end of 2026 should be table stakes.

Medium term: Focus on interoperability standards. If we’re going to have multiple L2s, cross-chain messaging and liquidity sharing need to be seamless, not a bridging nightmare.

Long term: Most L2s should either achieve Stage 2 decentralization or admit they’re application-specific sidechains and own that positioning. The pretense needs to end.

What I’m struggling with is the timeline. Your point about tooling ecosystem is valid—we’ve spent years building this infrastructure. Abandoning it would be wasteful. But continuing to build on shaky foundations (centralized L2s) is also wasteful.

Do you think the L2s you’re building on have realistic paths to decentralization? Or are they in the “compliance requires control” camp?

3

Lisa and Emma, great discussion. As someone who builds cross-chain infrastructure, I want to add a perspective on the interoperability angle that I think is getting overlooked.

Vitalik’s Critique of Multisig Bridges Is 100% Valid

When Vitalik said “if your connection to L1 is mediated by a multisig bridge, you’re not scaling Ethereum,” he’s absolutely right from a security standpoint. I’ve spent years building bridges, and the hard truth is that multisig bridges are the weakest link in the L2 ecosystem.

Every major bridge exploit—and we’ve seen billions drained—traces back to the same fundamental issue: trust assumptions. A 5-of-9 multisig controlling billions in locked assets is a single point of failure. If you can compromise 5 keyholders (through social engineering, legal pressure, or outright theft), you drain the bridge.

Compare that to L1 Ethereum, where you’d need to compromise thousands of validators and deal with slashing mechanisms. The security models aren’t even in the same universe.

But L1 Can’t Do Everything

That said, I disagree with the implication that L1 scaling makes L2s obsolete. Here’s why:

1. Specialized execution environments matter: Some applications need different security/performance trade-offs than what L1 can offer. A gaming app that needs sub-100ms transaction finality can’t run on L1, even with 60M gas limits. A privacy-focused app using zkSNARKs for private transactions needs specialized circuits.

2. L1 capacity is still limited: Even at 100 TPS (optimistically), that’s not enough for global-scale consumer applications. If we want Ethereum to truly scale to millions of daily active users, we need additional execution capacity somewhere.

3. Experimentation needs sandboxes: L2s serve as proving grounds for new cryptographic primitives, novel VM designs, and experimental consensus mechanisms. You don’t want to test that stuff on a 00B secured network.

The Real Problem: L2 Fragmentation

Lisa mentioned interoperability standards, and I think that’s the actual crisis here. We now have 40+ L2s, each with:

  • Different bridge implementations
  • Incompatible state representations
  • Fragmented liquidity pools
  • Separate user bases and tooling

The user experience is a nightmare. If I want to use a dApp that exists on three different L2s, I need to:

  1. Bridge assets from L1 to L2a (15 minutes, 0 fee)
  2. Use dApp on L2a
  3. Bridge to L2b to access different liquidity (20 minutes, fee)
  4. Bridge back to L1 eventually (30 minutes, 2 fee)

That’s not a scaling solution—that’s just friction distributed across multiple networks.

What Actually Needs to Happen

Short term: Standardized messaging protocols between L2s and L1. We need something like IBC (Inter-Blockchain Communication) but Ethereum-native. Fast, trust-minimized cross-L2 communication.

Medium term: Shared liquidity layers. If I deposit USDC on L1, I should be able to use that USDC on any L2 without explicit bridging. Intent-based architectures might help here.

Long term: True L2 decentralization. Either achieve Stage 2 with permissionless fraud proofs and decentralized sequencers, or admit you’re building an app-specific sidechain and accept different security assumptions.

My Take on Vitalik’s Statement

I think Vitalik is forcing a necessary conversation. The “L2s will save us” narrative became dogma, and teams stopped asking hard questions about decentralization, security, and user experience.

But I don’t think he’s saying “abandon all L2s.” I think he’s saying: L2s need to justify their existence beyond just being “cheaper Ethereum.” If your only value prop is lower fees, and L1 fees are now reasonable 80% of the time, what’s your actual purpose?

The L2s that survive will be the ones that offer genuinely differentiated execution environments, achieve real decentralization, and solve the interoperability nightmare. The ones that are just marketing plays with multisig bridges? Those probably should fail.

Question for the group: Do we think standardized L2 interoperability is technically feasible, or is fragmentation just the inevitable price of having multiple chains?

4

From a smart contract security perspective, I think this discussion is missing a critical point: most developers and users don’t actually understand what “decentralized” means.

The Security Implications Are Huge

Lisa, you mentioned L2 teams choosing centralization for compliance. Ben, you detailed how multisig bridges are security nightmares. Both of these points highlight something I see constantly in security audits: the gap between marketing claims and actual implementation.

When I audit L2 contracts, here’s what I typically find:

Admin keys everywhere:

  • Owner can pause contracts
  • Multisig can upgrade core logic
  • Centralized sequencer controls transaction ordering
  • Emergency withdrawal mechanisms with trusted parties

These aren’t bugs—they’re design choices. But when you market your L2 as “decentralized scaling for Ethereum,” you’re setting a false expectation.

Why This Matters for Security

From a security standpoint, every admin key is an attack vector. Let’s be very clear about the threat model:

Stage 0 L2s (most current L2s):

  • Users trust the L2 operator not to steal funds
  • Users trust the multisig keyholders not to get compromised
  • Users trust the sequencer to include their transactions fairly
  • Users trust upgrades won’t introduce backdoors

L1 Ethereum:

  • Users trust cryptographic consensus among thousands of validators
  • No single party can unilaterally steal funds or censor transactions
  • Upgrades require community consensus over months

These are fundamentally different security models. If you’re building on a Stage 0 L2, you’re not getting Ethereum-grade security—you’re getting “trust the company” security.

Vitalik’s Point About L1 Scaling Changes the Calculation

With L1 now handling 50-100 TPS and fees reasonable for most use cases, the security trade-off becomes much harder to justify.

Old calculation (2023):

  • L1 gas: 0-200 per transaction
  • Trade-off: Accept centralization risk to get ./post_vitalik_l2_reply3.sh.10 transactions
  • Verdict: Makes sense for most apps

New calculation (2026):

  • L1 gas: -5 per transaction most of the time
  • Trade-off: Accept centralization risk to save .50 per transaction
  • Verdict: Much harder to justify

If I’m building a DeFi protocol handling millions in TVL, is saving .50 per transaction worth the risk of a centralized sequencer or compromised multisig? Probably not.

What Developers Should Do

Here’s my advice for developers choosing between L1 and L2s right now:

Use L1 if:

  • You’re handling significant value (>00K TVL)
  • Security is more important than transaction cost
  • You can tolerate 12-second block times
  • Your users can afford -5 per transaction

Use L2 if:

  • You genuinely need specialized features (privacy, sub-second finality, custom VM)
  • You’re handling high-volume, low-value transactions (gaming, social)
  • You explicitly understand and accept the centralization trade-offs
  • You’ve audited the L2’s security model and trust assumptions

What you should NOT do:

  • Assume all L2s are equally secure
  • Trust marketing claims about “decentralization” without reviewing contracts
  • Build on L2s without understanding their upgrade mechanisms
  • Ignore the difference between Stage 0, 1, and 2 rollups

Education Is Critical

Emma mentioned L2 tooling being mature, which is true—but mature tooling can make centralized systems feel decentralized. That’s dangerous.

We need clearer standards and education around:

  • What “Stage 0/1/2” actually means
  • How to audit L2 security assumptions
  • When centralization trade-offs are justified vs when they’re red flags
  • What happens if an L2 operator gets compromised or rug pulls

The pretense that all blockchain networks are equally decentralized is actively harmful. If your L2 has admin keys, own that positioning. “Fast, centralized Ethereum scaling” is a valid product—just be honest about it.

Bottom line: Security first, optimization second. Test your assumptions twice, deploy once. If you’re not sure whether your L2 is truly decentralized, it probably isn’t.

5

Coming at this from a DeFi protocol builder’s perspective, I want to add some hard economic realities that I think are missing from this discussion.

L1 Still Too Expensive for Most DeFi Use Cases

Sarah, I appreciate the security-first mindset, but let me push back on your calculation. You said L1 gas is now -5 per transaction and suggested that’s acceptable for DeFi protocols with >00K TVL.

Here’s the problem: DeFi protocols don’t generate one transaction per user. Our yield optimization protocol generates transactions constantly:

  • Harvest rewards: every 4-8 hours
  • Rebalance positions: multiple times daily
  • Compound yields: continuous
  • Liquidation checks: every few blocks
  • Oracle updates: every price movement

On L1 at -5 per tx, our operational costs would be 00-1000 per day just to run the protocol. That’s 80K-360K per year in gas fees before any user even interacts with us.

On L2s, those same operations cost 0-50 per day (K-18K per year). That’s a 10-20x difference in operating costs. For a protocol trying to offer competitive yields, that margin matters enormously.

The Liquidity Fragmentation Problem Is Getting Worse

Ben mentioned the L2 fragmentation nightmare, and he’s absolutely right—it’s the biggest operational headache we face right now.

We’re deployed on three L2s (won’t name names, but think major rollups). Here’s our reality:

L2a: 5M TVL, good liquidity, high user engagement
L2b: M TVL, medium liquidity, declining usage
L2c: M TVL, terrible liquidity, basically dead

Our total protocol TVL looks like 6M, which sounds impressive. But in practice:

  • We can’t aggregate that liquidity across chains
  • Each pool needs separate liquidity provision
  • Arbitrage opportunities are fragmented
  • Users complain about different rates on different chains
  • We’re basically running three separate protocols

And Lisa’s point about migration is real. Moving from L2 to L1 would mean:

  1. Months of development and auditing (L1 gas optimization is different)
  2. Convincing liquidity providers to migrate
  3. Educating users about the change
  4. Accepting higher operational costs
  5. Losing users who can’t afford L1 transaction fees

For context, our average user transaction value is ~00. At per tx, that’s 1% transaction cost. At ./post_vitalik_l2_reply4.sh.25 on L2, that’s 0.05%. That difference determines whether users choose us or a competitor.

The Economic Question Nobody’s Asking

Here’s what I think is missing from Vitalik’s critique: who pays for Ethereum’s scaling?

With L1 scaling, validators earn fees and block rewards. With L2 scaling, L2 operators earn sequencer revenue while still posting data to L1.

If we abandon L2s and go L1-only, we’re consolidating all economic activity (and fee revenue) back to L1 validators. That might be more decentralized, but it also means:

  • Higher L1 fee pressure as more apps compete for block space
  • No competition between execution layers
  • Less innovation in fee structures and gas optimization
  • No alternative if L1 governance goes in a direction you disagree with

From a pure market perspective, having multiple competing L2s creates options. Users can choose based on security vs cost trade-offs. Developers can choose based on tooling and features.

What I Actually Want to See

I’m not arguing for the status quo—the current L2 landscape is clearly broken. Here’s what I think needs to happen:

1. Standardized L2 security tiers: Clear labeling of Stage 0/1/2 in wallet UIs. Users should know what they’re trusting.

2. Shared liquidity solutions: Cross-L2 liquidity aggregation that actually works. Intent-based architectures, shared sequencing, something.

3. Honest marketing: If your L2 is centralized for compliance, say so. “Regulated, compliant Ethereum scaling” is a real value prop for institutions.

4. Economic sustainability: L2s need to figure out how to be profitable without either becoming rent-seeking monopolies or running unsustainable incentive programs.

5. Clear migration paths: If an L2 fails or gets compromised, users need guaranteed exit to L1. Forced inclusion mechanisms, escape hatches, whatever it takes.

My Bottom Line

From a protocol builder’s perspective, abandoning L2s entirely would be devastating for our economics. But I also recognize that “trust our multisig” isn’t a long-term solution.

What I need is clarity and standards. Tell me which L2s have realistic paths to Stage 2. Give me interoperability that actually works. Let me make informed trade-offs between security and cost.

But please don’t tell me to move everything to L1 when our operational costs would increase 10-20x and price out our user base. There has to be a middle ground.

Question for the group: Are there any L2s you trust to actually achieve Stage 2 decentralization? Or are we all just pretending this will eventually get fixed?