PeerDAS Went Live on December 3rd, Blob Fees Jumped 15 Million Times, and L2 Costs Are Still Under a Penny - Inside Ethereum's Most Important Scaling Upgrade Since The Merge

[layer2_lisa]

I have been building L2 infrastructure for six years – first at Polygon Labs, then at Optimism Foundation, and now at a stealth rollup startup. In all that time, I have never seen a single upgrade change the economics of running an L2 as dramatically as Fusaka’s PeerDAS activation on December 3, 2025.

Let me break down what happened, why blob fees paradoxically jumped 15 million times while L2 costs dropped, and why this is the most important scaling milestone since The Merge.

What PeerDAS Actually Does (EIP-7594)

Before Fusaka, every Ethereum validator had to download every blob in every block to verify data availability. This created a hard ceiling: the network could only support as many blobs as the slowest validator could download. The practical limit was 6 blobs per block (target) and 9 (max).

PeerDAS (Peer Data Availability Sampling) fundamentally changes this. Instead of downloading everything, validators now:

1. Extended blob data is divided into 128 columns using erasure coding (Reed-Solomon)
2. Each node subscribes to at least 8 randomly chosen column subnets out of 128
3. Nodes only download 1/16th of all data (which represents 1/8th of the original data due to the 2x extension)
4. The network collectively verifies that all data is available through random sampling

This is not a minor optimization. It is an 87.5% reduction in bandwidth requirements for validators, which directly translates to the network being able to support dramatically more blobs per block.

The 15 Million-Fold Blob Fee Increase (EIP-7918)

Here is where it gets counterintuitive. Blob fees jumped 15 million times after Fusaka – and this is actually a good thing.

Before Fusaka, blob fees had a floor of 1 wei (essentially zero). This meant L2s were posting data to Ethereum for practically nothing, which sounds great until you realize:

• Validators were not being compensated for the compute cost of KZG proof verification
• Blob space had no meaningful price signal for congestion management
• ETH was not capturing any value from L2 transaction volume

EIP-7918 introduced a minimum blob base fee tied to L1 execution costs – specifically, at least 1/15.258 of the L1 execution base fee, equivalent to a minimum of 8,192 gas per blob. This creates a floor that reflects the actual computational cost of verifying blobs.

The result: blob fees went from 1 wei to approximately 15 million wei. In absolute terms, this is still incredibly cheap – we are talking fractions of a cent per blob. But the mechanism now properly prices the resource and contributes meaningfully to ETH burning.

The BPO Fork Innovation

One of the most underappreciated innovations in Fusaka is the Blob Parameter Only (BPO) fork mechanism. Instead of bundling blob capacity increases with major hard forks (which ship every 12-18 months), the Ethereum Foundation introduced lightweight parameter-only forks that can adjust blob targets independently.

The rollout has been aggressive:

Fork	Date	Blob Target	Blob Max	Capacity vs Pre-Fusaka
Pre-Fusaka	Before Dec 3, 2025	6	9	1x
BPO1	Dec 9, 2025	~10	15	1.67x
BPO2	Jan 7, 2026	14	21	2.33x
BPO3 (planned)	TBD	TBD	TBD	Target: higher
BPO4 (planned)	TBD	TBD	TBD	Target: 128 max

In just over a month, Ethereum more than doubled its blob capacity. The target of 128 blobs per block would represent a 21x increase from pre-Fusaka levels.

What This Means for L2 Costs

As an L2 engineer, here is what I am seeing in practice:

Data availability costs dropped 40-90% for most rollups within the first month of Fusaka. The exact savings depend on the L2’s blob usage patterns and timing, but the direction is unmistakable.

Average L2 transaction fees are now consistently under $0.01. For simple transfers on optimistic rollups, we are seeing fees in the $0.001-0.005 range. ZK rollups are slightly higher due to proof verification costs, but still dramatically cheaper than pre-Fusaka.

The economics have shifted from “data availability is our biggest cost” to “execution and proof generation are now the dominant expenses.” This is exactly the progression the Ethereum roadmap predicted.

The Bigger Picture: Ethereum as the DA Layer

What makes PeerDAS so significant is not just the immediate cost savings. It is the architectural statement: Ethereum is committed to being the dominant data availability layer, and it is willing to radically restructure its networking protocol to maintain that position.

The scaling roadmap beyond BPO4 includes full danksharding (EIP-4844’s endgame), which would push blob capacity even further. Combined with the gas limit increases to 80M+ that are being discussed, Ethereum is positioning itself to handle orders of magnitude more L2 throughput.

For L2 operators like me, this changes the competitive calculus. Alternative DA layers like Celestia and EigenDA had a compelling pitch when Ethereum’s blob space was constrained and expensive. With PeerDAS making Ethereum DA cheap and abundant, the security premium of posting data to Ethereum L1 becomes much harder to argue against.

Questions for the Community

1. For other L2 operators: what fee reductions are you actually seeing post-Fusaka?
2. How do you think the BPO mechanism changes Ethereum’s governance and upgrade cadence?
3. At 128 blobs per block, do alternative DA layers still have a viable market?

I would love to hear perspectives from different angles – protocol engineers, data analysts, traders, anyone who has been tracking this.

[blockchain_brian]

Lisa, excellent breakdown. As someone who has been contributing to the Ethereum consensus layer for years, let me add some technical depth on the protocol architecture decisions behind PeerDAS and why this upgrade was far more complex than most people realize.

The Erasure Coding Foundation

The 128-column design is not arbitrary. It is based on a specific mathematical property of Reed-Solomon erasure coding. The original blob data is extended by 2x, meaning you only need any 50% of the columns to reconstruct the full data. This gives us a crucial property: even if up to half the columns are missing from the network, any honest node can still recover the complete data.

The choice of 8 column subnets per node creates a probabilistic guarantee. With roughly 10,000 active validators each sampling 8 random columns, the probability that any single column goes unsampled is astronomically low – on the order of 10^-35. This is stronger than the security assumptions underlying most cryptographic primitives we rely on daily.

KZG Commitments: The Unsung Hero

What makes PeerDAS possible at all is the KZG (Kate-Zaverucha-Goldberg) commitment scheme that was introduced with EIP-4844 in the Dencun upgrade. Each blob comes with a KZG commitment – essentially a cryptographic fingerprint that lets any node verify that the data in their sampled columns is consistent with the commitment, without seeing the other columns.

This is fundamentally different from how data availability works on alternative DA layers. Celestia uses fraud proofs for DA, which introduces latency (you have to wait for potential fraud proofs before considering data available). Avail uses a similar KZG-based approach to Ethereum but lacks the validator set size and economic security. EigenDA leverages Ethereum’s security through restaking but adds an additional trust assumption layer.

Ethereum’s approach is what I would call “native DA” – the same validators securing the consensus layer are simultaneously providing data availability guarantees. No additional trust assumptions, no bridges, no secondary token economics.

The BPO Mechanism Is a Governance Innovation

Lisa mentioned the BPO forks, but I want to emphasize how radical this is from a governance perspective. Traditionally, every parameter change in Ethereum required a full hard fork with months of testing, coordination, and social consensus. The BPO mechanism essentially says: “We have already proven PeerDAS works. Now we just need to turn the knobs.”

The core developers designed BPO forks with specific safety criteria:

1. Network health monitoring – Each BPO only proceeds if the previous one shows stable network metrics (peer connectivity, block propagation times, missed attestation rates)
2. Gradual ramp-up – Rather than jumping straight to 128 blobs, they are incrementally increasing to gather real-world data at each level
3. Rollback capability – If a BPO reveals problems, the next one can reduce parameters back down

This is Ethereum learning from its own history. The EIP-1559 transition was a single dramatic change. PeerDAS is being rolled out as a series of carefully monitored increments. I think this approach should become the template for future parameter-sensitive upgrades.

What Is Left to Solve

PeerDAS is not the endgame. Full danksharding (as originally described in the Ethereum roadmap) would further increase throughput by implementing proposer-builder separation at the DA layer and potentially moving to 2D erasure coding. But PeerDAS gives Ethereum enough headroom for the next 2-3 years of L2 growth.

The bigger open question is whether the gas limit increases being discussed (80M+, potentially 180-200M by year-end) will create issues at the execution layer that PeerDAS cannot help with. Data availability and execution are separate bottlenecks, and solving one does not automatically solve the other.

What are your thoughts on the interaction between PeerDAS scaling and execution layer scaling? Are we going to hit new bottlenecks as blob capacity increases?

[data_engineer_mike]

This is exactly the kind of infrastructure discussion I live for. I have been tracking Ethereum’s blob economics from the data side since EIP-4844 launched with Dencun, and Fusaka has given us the richest dataset yet. Let me share what the on-chain numbers actually show.

Pre-Fusaka vs Post-Fusaka: The Numbers

I built a dashboard tracking blob usage, fees, and L2 posting patterns. Here is what the data reveals:

Blob utilization rate:

• Pre-Fusaka (6 target): Utilization frequently hit 90-100%, causing blob fee spikes
• Post-BPO1 (10 target): Utilization dropped to 55-65%, relieving congestion
• Post-BPO2 (14 target): Current utilization sits around 40-50%, with significant headroom

Blob fee economics:

• Pre-Fusaka average blob fee: Oscillated between 1 wei (off-peak) and spikes during congestion
• Post-Fusaka with EIP-7918: Stable floor at approximately 15M wei per blob
• In dollar terms: Individual blob cost went from effectively $0 to roughly $0.001-0.003 per blob

L2 posting frequency:

• Arbitrum: Increased blob submissions by ~35% post-BPO2
• Base: Most aggressive adopter, increased by ~50%
• Optimism: More conservative, ~20% increase
• zkSync and Starknet: Still optimizing their blob packing strategies

The ETH Burn Impact

This is where it gets interesting for anyone watching Ethereum’s monetary policy. I queried the burn data and here is what I found:

Pre-Fusaka, blob fees contributed essentially nothing to ETH burns (1 wei per blob is negligible). Post-EIP-7918, blob fees are now a measurable contributor. Based on current blob utilization rates and the minimum fee floor, I am projecting blob-related burns could represent 30-50% of total ETH burns by mid-2026, assuming L2 volume continues its growth trajectory.

The math works like this: at 14 blobs per block target with minimum fees of ~8,192 gas equivalent, and roughly 7,200 blocks per day, blob fees generate meaningful burn at scale. As we approach 128 blobs per block, this becomes a significant deflationary force.

Data Pipeline Challenges

From a data engineering perspective, PeerDAS created some interesting challenges. The old model where every node had every blob made indexing straightforward – you could run a single archive node and have complete blob data. With PeerDAS, reconstructing full blob data requires either:

1. Running a super-node that subscribes to all 128 column subnets (high bandwidth)
2. Aggregating data across multiple nodes (complex orchestration)
3. Relying on specialized blob archival services

For anyone running on-chain analytics, this is a non-trivial infrastructure change. I had to redesign my data pipeline (which I named “Goblin Slayer” after the anime – sorry, old habit) to handle the new column-based data structure.

What the Data Says About Alternative DA Layers

Lisa asked whether alternative DA layers still have a viable market at 128 blobs. Looking at the data, Celestia and EigenDA usage has not declined post-Fusaka – it has actually grown slightly. But the growth rate has decelerated compared to pre-Fusaka trends.

My interpretation: L2s that were already committed to alternative DA layers are not switching back, but new L2s are more likely to choose Ethereum-native DA now that it is cheap and abundant. The market is bifurcating rather than consolidating.

I would be happy to share my dashboard if anyone wants to dig into the raw numbers. What specific metrics are you all most interested in tracking?

[ethereum_emma]

Lisa and Brian, thank you both for the deep technical explanation. I want to bring this down to what PeerDAS means for developers like me who are building the applications that actually run on these L2s.

The Developer Experience Impact

I work as a full-stack developer at a DeFi protocol, and the fee changes from Fusaka have directly affected our product decisions. Before PeerDAS, we had to be incredibly careful about data costs. Every byte we posted to L1 had a real cost, and during blob congestion spikes, our users would see transaction fees jump unpredictably.

Post-Fusaka, I have noticed three concrete changes in my daily work:

1. We stopped optimizing for calldata compression. Before Fusaka, our team spent significant engineering time on compressing transaction batches to minimize blob usage. With 14-blob targets and sub-penny costs, the ROI on compression optimization has dropped dramatically. That engineering time is now going toward feature development instead.

2. Our fee estimation code got simpler. The old blob fee market was volatile – fees could spike 100x during congestion. With EIP-7918’s minimum fee floor and more abundant blob space, fee estimation is much more predictable. I actually removed about 200 lines of fee-spike handling code from our frontend last month.

3. We can now consider features that were previously too expensive. We had a whole backlog of features tagged “blocked: DA costs too high” – things like more frequent state updates, richer transaction metadata, and on-chain analytics data. With post-BPO2 pricing, several of these are now economically viable.

The Frontend UX Revolution

Here is something that does not get enough attention: cheaper L2 fees change the UX conversation entirely. When a transaction costs $0.003, you can start designing interfaces that do not even show the fee to the user. We are genuinely approaching the point where blockchain transactions feel as free as clicking a button on a website.

At our protocol, we are experimenting with a model where we sponsor all user transaction fees below $0.01 – essentially making the app free to use for normal interactions. Pre-Fusaka, this would have been unsustainable. Post-Fusaka, the cost of sponsoring fees for thousands of users is negligible.

What Still Worries Me

I want to be honest about what I find confusing, though. Brian mentioned KZG commitments and erasure coding, and while I understand the concept at a high level, the practical implications for application developers are still unclear to me.

For example: if I am building an application that relies on reading historical blob data (say, for transaction verification), does PeerDAS change how I access that data? Mike mentioned that data indexing got more complex – does that mean my application’s data queries might break or slow down?

Also, the 15 million-fold fee increase sounds scary when you first hear it. I know Lisa explained why it is actually good, but I have had conversations with non-technical stakeholders who see that headline and panic. How do we communicate this better to the broader ecosystem?

A Practical Question

For other developers here: has anyone had to change their smart contract architecture or deployment strategy because of PeerDAS? I am curious whether the changes are purely at the infrastructure level or if application-layer code needs updating too.

[crypto_chris]

Great thread. Let me add the market perspective, because PeerDAS is not just a technical upgrade – it is repricing the entire Ethereum investment thesis.

The Value Accrual Thesis Just Got Stronger

For the past year, the biggest bear case against ETH has been the “value accrual problem”: L2s capture all the transaction fees, Ethereum L1 gets almost nothing, and ETH has no reason to appreciate. The numbers backed this up – blob fees at 1 wei meant L2s were essentially using Ethereum’s security for free.

EIP-7918 changes this equation meaningfully. Mike’s projection of blob-related burns representing 30-50% of total ETH burns by mid-2026 is significant. If L2 transaction volumes continue growing (and the data suggests 3-5x growth is plausible as fees drop below $0.01), blob fees become a genuine deflationary force for ETH.

This matters for price. ETH has been the worst-performing major crypto asset in 2026, down 36% while BTC and SOL have held up better. The narrative has been that Ethereum is losing the value war to its own L2s. PeerDAS does not fully solve this, but EIP-7918’s minimum fee floor creates a much cleaner story: “Every L2 transaction generates demand for blob space, blob space costs ETH, and that ETH gets burned.”

The Competitive DA Market

Lisa asked about alternative DA layers at 128 blobs. Here is how I am thinking about it from a market structure perspective:

Celestia (TIA): The investment thesis was “Ethereum DA is too expensive and too limited, so L2s will pay Celestia for cheaper DA.” Post-PeerDAS, Ethereum DA is neither expensive nor limited. Celestia needs to pivot its narrative to “modular DA for non-Ethereum ecosystems” or “DA for chains that want more customization.” The TIA token has already reflected this – it is down significantly from its highs.

EigenDA: Positioned as “Ethereum-secured DA through restaking.” This is more resilient because it leverages Ethereum’s validator set, but it faces the question of why L2s would pay for EigenDA when native Ethereum DA is now cheap. The answer might be specific technical features (lower latency, higher throughput), but the cost advantage has evaporated.

The winner: Ethereum L1 DA. When you can get security from the largest validator set in crypto, settlement on the most liquid chain, and data availability for fractions of a cent – the value proposition of alternative DA becomes niche rather than mainstream.

Trading Implications

For traders, here is what I am watching:

1. ETH/BTC ratio: If the blob burn thesis plays out, ETH should start recovering relative to BTC. The ratio is at multi-year lows, which means the risk/reward on a mean reversion trade is attractive.

2. L2 token repricing: Cheaper DA means higher margins for L2 operators, which should be positive for tokens like OP and ARB. But it also means the “L2 fee revenue” narrative is less differentiated – if everyone’s DA costs drop to near zero, the competitive advantage shifts to execution and user acquisition.

3. DA token underperformance: I expect continued pressure on TIA and similar tokens as the market prices in Ethereum’s improved DA competitiveness.

The BPO mechanism is also worth watching from a trading perspective. Each BPO fork is a potential catalyst – if BPO3 and BPO4 proceed smoothly and the network handles 128 blobs without issues, it reinforces the bull case for ETH as the dominant settlement and DA layer.

What are others seeing in terms of on-chain flow data around the Fusaka upgrade?