Blobs at 30% Capacity - Why Scale L1 Further Before We Fill What We Have?

[layer2_lisa]

The Ethereum Foundation just published a major update to their L1/L2 vision on March 23—the first substantial revision in roughly five years. One statement jumped out at me:

“L1 and Blobs are currently only ~30% full, and we aim to scale up L1 and Blob capacity to cater to the increasing demand.”

As someone who’s spent the last 6 years building L2 infrastructure at Polygon and Optimism, this raises a fundamental question: Why are we planning to expand capacity when we haven’t filled what we already have?

The Current State of Blobs

EIP-4844 blob transactions launched with the Dencun upgrade in March 2024—over two years ago now. The specs were:

• Target: 3 blobs per block (0.375 MB)
• Maximum: 6 blobs per block (0.75 MB)
• Purpose: Provide temporary data availability for rollups at lower cost than calldata

After launch, blob usage started around 10K blobs per day and has grown to approximately 17K blobs daily as of Q1 2026. Major L2s like Arbitrum, Base, and Optimism have adopted blob transactions. Blob fees dropped dramatically—rollups saw a 72% decrease in average fees per block (from 0.075 ETH to 0.021 ETH).

That’s all great. But here’s the thing: we’re nowhere near saturating current capacity, even after two years of adoption.

Why Scale Before Hitting Capacity?

I can think of a few possible explanations for the Foundation’s approach:

1. “Build it and they will come”
Maybe the strategy is to have abundant capacity ready so it’s never a bottleneck. When L2s know capacity is plentiful, they might post state updates more frequently, experiment with data-heavy applications, or lower fees more aggressively.

2. ZK technology maturation
The Foundation’s blog mentions that ZK tech “has matured faster than initially anticipated, opening new scaling paths.” Perhaps advances in proof systems make more aggressive L1 scaling viable sooner than expected.

3. Marketing and commitment signaling
Announcing scaling plans demonstrates ongoing commitment to the roadmap, even if demand hasn’t materialized yet. It’s a psychological message to developers and institutions: “Ethereum will scale, keep building here.”

4. Capacity isn’t the real bottleneck anyway
From my experience, the bigger problems are UX fragmentation (15+ different L2s with incompatible states), security assumptions (varying trust models), and bridge complexity. If those are the real bottlenecks, expanding blob capacity doesn’t hurt—it just prepares infrastructure for when other issues are resolved.

The Fragmentation Problem

Here’s my concern: after three years of heavy L2 development, Vitalik himself said earlier this year that L2s are “not scaling Ethereum”—pointing to fragmented liquidity, inconsistent security, and reliance on centralized components.

Over 50% of Ethereum developers now work on L2s (up from 25% in 2022). That’s a massive ecosystem investment. Yet the result isn’t “Ethereum scaled”—it’s “Ethereum fragmented into 15+ semi-independent chains.”

If we build more L1 capacity but don’t solve the coordination problem between L2s, are we just preparing infrastructure for a fragmented future?

My Take

As an L2 engineer, I see this as infrastructure overcapacity meeting a coordination problem. The Foundation can control L1 capacity (that’s within their domain), but they can’t force L2s to standardize, share liquidity, or improve interoperability (that’s a coordination problem among independent entities).

So maybe scaling L1 is the rational move even if it’s not addressing the main bottleneck. It’s something the Foundation can do, while L2 fragmentation is something they can only influence indirectly.

But I’m genuinely curious what others think:

Is expanding L1/blob capacity while sitting at 30% utilization smart preparation for future demand? Or is this infrastructure overcapacity while we ignore the real UX and coordination issues?

Would love to hear perspectives from developers, protocol operators, and anyone thinking about Ethereum’s scaling endgame.

[ethereum_emma]

This is such a great question, Lisa! You’re coming at this from the infrastructure side, but I want to add a perspective from someone who builds DeFi frontends and actually tries to onboard users.

The real bottleneck isn’t capacity—it’s the user experience nightmare.

I just spent last weekend trying to help a non-crypto friend use a DeFi lending protocol. She got as far as connecting her wallet, then hit the L2 selection screen. The conversation went like this:

“Do I use Arbitrum, Optimism, Base, Polygon zkEVM, or zkSync?”
“Well, it depends on where your funds are…”
“I don’t know where my funds should be. Which one is cheapest?”
“They’re all pretty cheap now with blobs, but you need to bridge first…”
“Bridge? I thought I was just borrowing USDC?”

She gave up. And honestly, I don’t blame her.

More Capacity Doesn’t Fix Fragmentation

You mentioned this in your post, but I want to emphasize it from the developer perspective: scaling L1 capacity doesn’t solve the problem that users experience 15 different “Ethereums” and don’t know which one to use.

From my work integrating wallet connections and managing multichain state, here’s what actually blocks adoption:

1. Which L2 to use? No clear answer for users
2. Bridging friction: Every bridge has different security models, wait times, and interfaces
3. Fragmented liquidity: The token I want isn’t on the L2 I’m using
4. Different addresses, balances, transaction histories across chains—even though it’s “all Ethereum”

Maybe I’m missing something technical here (and I’m genuinely asking, not arguing), but it seems like we’re optimizing the wrong metric. Transaction capacity is abundant. User clarity is not.

Shouldn’t We Prioritize L2 Interoperability?

I keep hearing about “shared sequencers,” “cross-L2 bridges,” and “liquidity abstraction layers,” but these feel like band-aids on the fragmentation problem rather than real solutions.

If the Foundation has the influence to push L1 scaling forward, could they also push for:

• Standardized L2 interoperability protocols?
• Unified user-facing abstractions (so users don’t need to know which L2 they’re on)?
• Better developer tooling for multichain state management?

Or is that outside their domain, and each L2 is going to keep building their own walled garden?

From the User’s Perspective

When I talk to non-crypto people about Ethereum, they don’t say “I wish transactions were cheaper” (they’re already cheap on L2s). They say “This is way too confusing.”

More blob capacity might prepare us for a future where millions of transactions happen daily. But if those transactions are spread across 15+ incompatible chains with terrible UX, did we actually scale Ethereum—or just scale the confusion?

I realize I’m probably oversimplifying the technical trade-offs here, so I’d love to hear if there’s a reason why expanding capacity now makes sense even if we haven’t solved fragmentation. Maybe the two problems are independent and we can work on both in parallel?

But yeah, from where I sit building frontends and trying to onboard users: more capacity ≠ better UX.

[defi_diana]

Great analysis from both Lisa and Emma. Coming from a DeFi protocol operator perspective, I want to offer a slightly different angle—one that’s more about economic incentives and capacity planning.

The Economic Case for Abundant Capacity

Lisa’s data is accurate: blobs are sitting at ~30% utilization. Emma’s point is also valid: fragmentation is a bigger UX problem than capacity. But here’s the thing—capacity constraints change behavior in ways that might not be obvious from utilization numbers.

Think of it like a restaurant. If you’re running at 30% capacity, you might think “why expand the dining room?” But if customers know you often run at 80-90% capacity during peak hours, they change their behavior:

• They make reservations further in advance
• They avoid peak times
• They choose competitors with more availability
• They don’t experiment with new menu items (risk of wasted capacity)

Similarly, when L2s know blob capacity is constrained, they optimize differently:

1. Conservative state updates: Post less frequently to avoid blob fee spikes
2. Fee pressure: Keep user fees higher as insurance against capacity crunches
3. Innovation hesitation: Don’t experiment with data-heavy applications that might hit capacity limits

But if the Foundation credibly signals “we have tons of headroom and will keep expanding,” L2s might:

1. Post more frequent state updates → better finality UX
2. Lower fees more aggressively (knowing blob fee spike risk is minimal)
3. Experiment with new data-heavy use cases (gaming state, social graphs, etc.)

So even at 30% utilization, abundant capacity changes the game theory.

Capacity Planning Has Lead Time

From an operational perspective, there’s another consideration: by the time you hit 80% utilization, it’s too late to start scaling.

Infrastructure changes at the Ethereum L1 level take:

• 6-12 months for research and specification
• 6-12 months for implementation and testing
• 6+ months for coordination and deployment

That’s 2-3 years total in the best case.

If blob usage suddenly spikes (maybe because of some killer app no one predicted), and we’re already at 70-80% baseline utilization, we’d hit capacity constraints long before any upgrade could ship.

Better to scale when network is NOT under stress, test the changes carefully, and have headroom ready.

The Messaging Confusion

That said, I agree with Lisa that there’s something confusing about the messaging:

• “We need to scale L1/blob capacity” (implies urgency)
• “We’re only at 30% utilization” (implies no urgency)

These seem contradictory. Is 30% the new target utilization rate? Like, we intentionally want to stay below 40-50% so we never hit capacity constraints?

Or are we waiting until 60-70% utilization before actually implementing the scaling plans?

The economic difference matters:

• If target is 30% utilization: L2s can confidently plan around abundant capacity
• If we’re waiting to scale until 70% utilization: L2s should still optimize conservatively

Would love clarity on this from anyone following the Foundation’s roadmap more closely.

Emma’s Point Still Stands

Even with all this economic/capacity planning logic, Emma is absolutely right that fragmentation is the bigger problem for adoption.

I run yield optimization bots that need to monitor liquidity across 15+ L2s. The complexity is absurd. Users don’t care about blob capacity—they care about “can I easily move my money where the yield is?”

So maybe the answer is: we need both.

• Scale L1 capacity (Foundation can control this)
• Push L2 interoperability standards (Foundation can influence but not control)

The question is whether both efforts are happening in parallel, or if L1 scaling is getting all the attention because it’s the easier problem to solve.

Curious what others think: Is 30% the target utilization rate, or are we waiting to hit higher utilization before actually expanding capacity?