Ethereum’s Blob Market After Fusaka: Scaling Became a Control Problem

0x6b970885c6Ee83A185D1396F884AF20e6B5f46bb
Published Oct 15, 2026

An editorial map of Ethereum’s post-Fusaka data-availability control loop

Ethereum no longer scales rollup data by asking every node to carry every byte. The post-Fusaka system coordinates sampled availability, scheduled capacity changes, and a fee signal—three mechanisms that must work together.

Research date: 15 October 2026. This report distinguishes current protocol parameters from dated market observations. It is analysis, not investment advice.

Executive summary

Ethereum’s Fusaka upgrade, activated on 3 December 2025, is best understood not as a one-off capacity increase but as a redesign of how the network governs scarce data availability. PeerDAS changed the physical constraint: ordinary nodes can verify that rollup “blob” data is available by sampling portions of it instead of downloading every blob in full. Blob-Parameter-Only (BPO) forks changed the operating cadence: preconfigured steps can adjust blob targets and maxima without waiting for another named upgrade. EIP-7918 changed the economic feedback: it prevents the blob base fee from becoming detached from the execution cost that blob-carrying transactions impose.

Together, these changes created a control system. Rollups submit demand; a target-based fee mechanism signals congestion; protocol developers can release additional capacity in monitored steps; distributed sampling keeps the bandwidth burden from rising one-for-one with system throughput. The result is material: after two scheduled BPO steps, Ethereum moved from a pre-Fusaka target/maximum of 6/9 blobs per block to 14/21—roughly 2.3 times the targeted data space, according to the Ethereum Foundation’s January 2026 checkpoint.

The early evidence argues against both triumphalism and pessimism. A reproducible mainnet replay covering 6 August–4 September 2026 found an average of 5.2045 blobs per block, only 37.17% of the target, while the 95th and 99th percentiles reached 14 and 19. Demand was therefore slack on average but sharply bursty. Only 4.41% of blocks were above target and 0.525% hit the maximum; no rolling 300-block window averaged above 14. This is not sustained scarcity. It is also not an empty market: short bursts already test the upper range.

Our thesis is that Fusaka has bought Ethereum an operating window, not solved scaling permanently. Cheap, abundant blobspace supports rollup growth, but suppresses near-term scarcity revenue. Sampling protects ordinary nodes, but higher aggregate throughput still raises networking and storage obligations for some participants. And BPOs make supply adjustment faster, but they do not eliminate the social judgment about when capacity should rise. Investors and operators should now watch the behavior of the control loop—utilization distribution, burst duration, fee responsiveness, node health, and demand concentration—rather than treating a single transaction-per-second number as the verdict.

From a product launch to an operating system

Blobs arrived with Dencun in March 2024 as ephemeral data containers built for rollups. They separated the data-availability bill from ordinary execution gas, allowing rollups to publish compressed transaction data to Ethereum without bidding for the same space as conventional transactions. Pectra, activated in May 2025, raised the target from three to six blobs per block and the maximum from six to nine. Fusaka then supplied the architectural prerequisite for going further.

The official Fusaka overview records activation on 3 December 2025. The first BPO raised target/maximum parameters to 10/15 on 9 December; the second raised them to 14/21 on 7 January 2026, as specified in the mainnet announcement. Those dates matter. Saying “Fusaka supports more blobs” obscures the deliberate sequence: activate sampling first, observe the network, then raise capacity in bounded steps.

timeline
    title Ethereum's blob-capacity staircase
    March 2024 : Dencun activates blobs
               : Target 3, maximum 6
    May 2025 : Pectra raises capacity
             : Target 6, maximum 9
    3 Dec 2025 : Fusaka activates PeerDAS
               : Parameters initially stay 6 and 9
    9 Dec 2025 : BPO1
               : Target 10, maximum 15
    7 Jan 2026 : BPO2
               : Target 14, maximum 21

This sequencing turns upgrade governance into capacity management. Under EIP-7892, BPO forks are part of client configuration and are intended to alter only blob-related parameters. They still require consensus and client readiness; “parameter only” does not mean governance-free. But the narrower scope reduces coordination overhead and makes reversibility and observation more credible than bundling every adjustment into a large, infrequent fork.

Why PeerDAS changes the constraint

Before Fusaka, a full node needed to download all blob data associated with a block to check availability. That design makes total network blob throughput and individual-node bandwidth grow together. PeerDAS, standardized in EIP-7594, erasure-codes blob data into columns and distributes custody across the peer-to-peer network. Nodes request samples; enough successful random samples provide high confidence that the full data can be reconstructed.

The crucial distinction is between availability and execution. Ethereum is not asking every validator to execute every rollup transaction. It is ensuring that the data needed to reconstruct and challenge or verify a rollup is present. Sampling reduces what any ordinary node must retrieve while preserving a collective availability guarantee. That is the basis on which aggregate capacity can grow faster than per-node load.

flowchart LR
    A[Users transact on rollups] --> B[Rollups compress transactions]
    B --> C[Blob-carrying transaction]
    C --> D[Erasure-coded data columns]
    D --> E1[Node samples assigned columns]
    D --> E2[Other peers sample other columns]
    D --> E3[Supernodes retain all columns]
    E1 --> F{Enough independent samples?}
    E2 --> F
    E3 --> F
    F -->|Yes| G[High-confidence data availability]
    G --> H[Rollup state settles on Ethereum]
    F -->|No| I[Block is not accepted as available]

Sampling is not magic compression, and the asymmetry matters. The ethereum.org PeerDAS explainer describes PeerDAS as a step toward full data-availability sampling, not the final form of Danksharding. “Supernodes”—high-balance nodes that custody all columns and help repair missing data—carry materially larger obligations. Ethereum’s Fusaka page estimates that at a future six-times-pre-Fusaka blob target, such nodes would need roughly 600 GB of additional blob storage and about 20 Mbps of sustained download bandwidth. Those are roadmap estimates, not measurements of every current node, but they expose the trade-off: decentralization is protected by distributing work, not by making work disappear.

Capacity is abundant; demand is uneven

A capacity staircase compared with a fixed September 2026 demand sample

Capacity moved from 3/6 at Dencun to 14/21 after BPO2. The orange line is a dated 30-day mean, not a live reading; it reveals spare average capacity alongside sharp tails.

The most useful public measurement located for this report is a reproducible 90-day mainnet replay covering 645,600 blocks and 2.86 million blobs from 7 June through 4 September 2026. Its detailed 30-day window, 6 August–4 September, provides a clean snapshot of the current 14/21 regime.

Metric, 6 Aug–4 Sep 2026

Observed value

Interpretation

Average blobs per block

5.2045

37.17% of the 14-blob target

Median

4

A typical block remained well below target

95th / 99th percentile

14 / 19

Tail demand regularly reached target territory

Zero-blob blocks

18.37%

Demand was not evenly distributed

Blocks above target

4.41%

Fee-increasing pressure was occasional

Blocks at 21-blob maximum

0.525%

Hard-cap events occurred, but were rare

Longest maximum-size run

4 blocks

Saturation was brief

300-block windows above target

0%

No sustained target breach in the sample

These figures should not be mistaken for an official Ethereum Foundation dataset; they are a third-party replay with disclosed methodology and a fixed end date. They are valuable precisely because the sample, assumptions, and correction history are visible. Current explorers such as Blobscan should be consulted for live conditions.

The distribution tells a richer story than the average. At 5.2 blobs per block, a simplistic reading says Ethereum overbuilt. At the 99th percentile of 19, a simplistic reading says scarcity is close. Both miss the control objective: spare average capacity absorbs growth, while the fee mechanism must respond to bursts before the cap becomes a persistent service constraint. A healthy market can have low mean utilization and still benefit from a responsive price at the tail.

The price floor repairs the signal

Blob fees use a target-based adjustment mechanism: sustained use above target pushes the base fee up, while use below target lets it fall. But blob transactions also consume execution gas. Before Fusaka, when the blob fee sat near its minimum, execution cost could dominate the total publication bill. The nominal blob price could then remain economically trivial even as blobs imposed real computational costs, weakening the congestion signal.

EIP-7918 addresses that mismatch by bounding the blob base fee relative to the cost of executing a blob-carrying transaction. When the calculated reserve exceeds the nominal blob base fee, the update rule treats the block in a way that prevents continued decay and permits the fee to recover. The mechanism is subtle: it does not promise high fees, guarantee ETH value accrual, or turn unused capacity into revenue. It makes the signal harder to pin at an irrelevant minimum.

For rollups, abundant capacity plus a reserve price is a better planning environment than cheap space with a broken feedback mechanism. For ETH economics, however, the implication is more nuanced. Lower data costs can attract usage and strengthen Ethereum’s role as a settlement and availability layer, yet low utilization necessarily limits immediate blob-fee burn. The investment case therefore depends on demand compounding into the expanded envelope, not merely on the envelope’s existence.

What the activity layer says—and does not say

L2 activity validates the direction of travel. L2BEAT’s activity dashboard showed rollup activity many multiples of Ethereum L1 during 2026, though its values are live and should be read with their timestamp and category definitions. This confirms that execution is increasingly happening away from L1. It does not prove that all such activity creates equal blob demand: compression ratios differ, some systems use alternative data-availability arrangements, and high-frequency applications can batch efficiently.

The chain of causality therefore runs through several filters:

flowchart TD
    A[More L2 user operations] --> B{Posted to Ethereum DA?}
    B -->|No| C[No Ethereum blob demand]
    B -->|Yes| D[Compression and batching]
    D --> E[Blobs required]
    E --> F{Average use versus target}
    F -->|Below| G[Low scarcity revenue and room to grow]
    F -->|Persistently above| H[Fee rises and capacity pressure appears]
    H --> I{Node health and safety margin acceptable?}
    I -->|Yes| J[Consider later BPO increase]
    I -->|No| K[Hold capacity; optimize networking]

That is why transaction counts alone are an incomplete valuation metric. Analysts need to connect user operations to bytes posted, fees paid, posting concentration, and the security model under which the data is made available.

Implications for institutions

For rollup operators, the expanded target is a cost and reliability buffer. The most defensible strategy is not to assume permanently negligible fees, but to treat blob publication as a variable input with tail risk. Bursty demand makes scheduling, compression, and fee ceilings financially relevant even when the monthly average looks benign.

For node operators, averages are again insufficient. Sampling lowers the ordinary-node burden relative to downloading every blob, but peak ingress, peer quality, custody duties, and storage policies determine resilience. A network can look underutilized economically while still experiencing short networking stress. Monitoring missed attestations and data-reconstruction performance around peaks is more informative than watching fee charts alone.

For ETH holders and protocol investors, Fusaka improves the scalability of Ethereum’s product, but product capacity and token cash flow are not synonyms. Near-term slack is intentional insurance for growth. The bullish case is that lower rollup costs stimulate applications, deepen settlement demand, and eventually fill the expanded data market. The countercase is that competition among data-availability layers, better compression, or migration to non-rollup designs keeps Ethereum blob demand below the level required for material fees.

For governance observers, BPOs create a new accountability surface. Parameter changes should be judged against transparent thresholds: sustained utilization rather than isolated full blocks, fee behavior, geographic and client-level node health, reconstruction success, and concentration among blob submitters. Faster knobs are valuable only if their use remains legible.

Risks and counterarguments

The first risk is premature expansion. Raising targets while demand is far below them can delay price discovery and revenue, while transferring more bandwidth and storage burden to infrastructure providers. The response is not to freeze capacity automatically; it is to require evidence that additional headroom produces user value commensurate with operational cost.

The second is hidden centralization. PeerDAS limits what ordinary nodes download, but highly provisioned supernodes and well-connected relays may become more operationally important. If reconstruction performance depends on a narrow set of providers, nominal validator counts could overstate practical resilience.

The third is demand concentration. A small number of rollups can dominate blob posting. Their software changes, compression upgrades, or migrations can move demand abruptly, so historical utilization may not extrapolate smoothly.

The fourth is measurement ambiguity. “Blobs per block” ignores how full each blob is, while L2 transactions ignore compression and DA choice. Fee revenue is influenced by ETH price and execution cost as well as blob usage. No single dashboard resolves these dimensions.

Finally, the control loop itself is partly social. Sampling and fee adjustment are protocol mechanisms; the decision to schedule later BPOs reflects developer and community risk tolerance. Ethereum has made the knob narrower and safer, not apolitical.

Conclusion

Fusaka’s durable contribution is a change in operating philosophy. Ethereum can now expand rollup data capacity through monitored steps because PeerDAS weakens the link between total throughput and each ordinary node’s download burden. The 14/21 regime has delivered substantial headroom, and the best available late-summer sample shows why that headroom should be interpreted carefully: average demand was modest, but the tail was real.

The next proof point is not another headline maximum. It is whether Ethereum can convert inexpensive capacity into durable, diverse demand while preserving a meaningful congestion signal and observable node health. If it can, blobspace becomes credible infrastructure: cheap when spare, priced when scarce, and scalable without excluding ordinary operators. If it cannot, the system will have demonstrated technical capacity without resolving the economic and decentralization trade-offs that make capacity valuable.

Sources and methodology