Fusaka Nears Mainnet: PeerDAS and the Coming Blob Market

Breaking: the dates, the plan, the promise

Ethereum core developers have set an ambitious finish to 2025. Public testnets are rolling out through October on Holesky, Sepolia, and Hoodi, with a mainnet target of December 3. That schedule comes directly from All Core Developers Consensus discussions, which also outline follow up steps that raise blob capacity in stages soon after mainnet. The sequencing is designed to land before year end, while leaving room for safety checks between milestones. See the ACDC 165 agenda and schedule.

The headline feature is PeerDAS, short for peer data availability sampling. If you are building on a rollup, PeerDAS lands like a new highway that removes the lane closures left after EIP 4844. On top of that, a pair of blob parameter only upgrades are slated to increase the number of blobs per block in quick succession after Fusaka is live. Together, these changes push down the biggest cost line item for optimistic and zero knowledge rollups: paying to make their data available on Ethereum.

Why this upgrade matters for real users

Every payment, game move, or in app action written to a rollup eventually gets summarized and posted to Ethereum in a package of data called a blob. Today those blobs are precious. When demand spikes, rollups pay more to post data. Users feel that as higher fees and some applications back off to keep costs predictable. For more context on how lower fees unlock consumer use, see how stablecoin payments go mainstream.

PeerDAS takes pressure off each individual node by changing how the network checks that blob data was actually published. If the network can check more data with less strain, Ethereum can safely carry more blob capacity. When capacity increases and verification becomes cheaper, rollups have room to breathe. Stablecoin payments get cheaper. Microtransactions that were not worth the fee can start to make sense. New consumer flows like in game item trades or creator tipping no longer need to wait for off peak windows.

Testnets are not just dry runs. They are the opportunity to measure what this means for your product. With testnet forks landing across October, teams can load test, tune posting strategies, and validate that wallets, bridges, relayers, and indexers behave the same under higher blob supply and different sampling patterns.

PeerDAS in plain English

Imagine your neighborhood needs to confirm that a huge mural was painted correctly on a long wall. In the old world, everyone walked the entire length of the wall. It took time, and not everyone could do it. With PeerDAS, the neighborhood splits the job. Each person checks a few tiles, and the pattern is designed so that if every tile spot checks correctly, you can be confident the full mural is present. That is data availability sampling.

Under the hood, blobs are erasure coded so they can be reconstructed from pieces. Validators and other participants sample small portions from peers rather than downloading every byte. They authenticate those pieces against commitments that were included in the block. If the samples check out, the network is confident the full blob is available. If anyone tries to hide data, the sampling detects it with very high probability.

PeerDAS does not change the economic role of blobs, it changes the cost structure of verifying them. Less bandwidth and disk pressure per node means the network can safely increase usable data throughput without centralizing. The formal proposal is the EIP 7594 PeerDAS specification.

Phased blob expansions, explained simply

Blobs are capacity units for rollup data. Ethereum already targets a certain number of blobs per block and allows a maximum above that target, similar to how a gas limit caps computation. Fusaka focuses on PeerDAS and related plumbing. Soon after activation, developers plan two small follow up upgrades that only touch blob parameters. The first increase lifts the per block blob allowance, and the second lifts it again. Combined, the two steps more than double today’s capacity. Staging them lets client teams observe real conditions, collect propagation metrics, and check for regressions while still delivering meaningful relief to rollups during the holiday traffic season.

For product teams this matters in two concrete ways:

The cost of posting rollup data should trend down as supply increases, although demand will move too.
Posting strategies can become smarter. You can smooth batch sizes across a wider capacity envelope, cut worst case fee spikes, and shrink the time between user action and final posting.

How PeerDAS and more blobs cut rollup costs

Rollups pay three big bills to deliver a single user action:

L1 data availability, paid in blob base fees and included with the block
L2 sequencing, paid to the rollup operator or shared builders and relays
Proofs or fraud windows, which determine how long until the action is final and how often expensive proof computations run

Of these, the first has dominated since Dencun. That is why PeerDAS plus more blobs is potent. By sampling, the network can handle more data per unit time without overloading nodes. By lifting blob counts in measured steps, Ethereum creates more room for rollups to post. More room lowers clearing prices. When posting cheapens, wallets can pass savings through to users or absorb them to subsidize growth periods. For the evolving proof landscape, see how proof markets hit mainnet.

There is also a latency angle. If rollups no longer need to queue data during blob squeezes, the path from user click to posted data shortens. That makes cross rollup payments more predictable. It also reduces the number of edge cases that support teams see when a message is confirmed on L2 but has not yet been posted to L1.

The coming blob market

Call it a market because it has buyers, sellers, and a price signal every block. Buyers are rollups and the applications that need their data posted. Sellers are the block builders that include blobs. The base fee adjusts as demand changes. When supply expands and verification costs fall, the market gets more competitive. For builder dynamics and policy debates, revisit ePBS and builder policy.

Expect three forms of competition to play out:

Time of day pricing. With more capacity, the difference between peak and off peak blob prices should compress, but it will not disappear. Savvy rollups will still schedule large, non urgent postings during cheaper windows.
Quality of batching. Rollups that pack transactions more efficiently will consistently beat rivals on cost per user action. Wallet teams can help by grouping payments and consent messages to fill batches cleanly.
Cross domain routing. Bridges, payment routers, and games that span multiple rollups will learn to chase cheaper blob lanes in real time. If a user can settle the same value on two routes, the route with lower blob prices and similar latency will win.

This market will not be static. The two planned parameter bumps are near term steps. If PeerDAS performs as expected, developers will have better data to consider further changes in 2026. That does not guarantee more increases, but it keeps the door open to scale when evidence supports it.

What this means for stablecoin payments

Stablecoin transfers are the cleanest early beneficiary because they are simple, frequent, and sensitive to fees. Lower data posting costs translate directly into lower end user costs because most stablecoin transactions are tiny messages that rollups batch in blobs. Liquidity providers can rebalance across rollups more often because the fee to settle state roots is lower. Merchants that want predictable fees can lock routing to rollups that consistently post within capacity instead of waiting out high price blocks.

If your wallet supports recurring payments, streaming payroll, or point of sale flows, begin testing fee surfaces now. In October you can measure end to end from the moment a user authorizes a transfer to the moment the batch hits a testnet block with PeerDAS style sampling live. Work with your settlement partners to design guardrails, like maximum acceptable blob base fees and automatic route switching.

A 90 day builder playbook to ship ahead of mainnet

Below is a concrete timeline from Monday, October 13, 2025 through Sunday, January 11, 2026. The goal is to have production ready features in users’ hands before mainnet, with a quiet period for monitoring and safety checks.

Weeks 1 to 2, Oct 13 to Oct 26

Upgrade dependencies. Pull client releases and libraries aligned with the Fusaka testnets. Pin versions so staging and test labs are consistent across your infra.
Deploy to Holesky and Sepolia. Holesky forked on October 2, so stand up nodes and indexers there today. Target Sepolia by October 20 to validate behavior across two networks.
Add blob price telemetry. Expose blob base fee, target utilization, and effective batch sizes to your ops dashboards. If you run a rollup, publish a public status page so integrators can see your posting cadence.
Wallets: add a field in the send panel that estimates the L1 data component separately from the L2 component. Teach users why fees are dropping so support tickets go down, not up.

Weeks 3 to 4, Oct 27 to Nov 9

Hoodi rehearsal. Forks are expected around October 28 to 30. Re run your highest load test with real traffic patterns, not just synthetic spam. Capture p95 posting delays, not only averages.
Configure posting guards. For applications that batch messages, add rules that cap batch age and cap maximum blob fee per unit of data. If either cap triggers, fall back to a second route or post a partial batch.
Games: precompute content hashes for assets you plan to roll out in December so content addressing is fixed before mainnet. That avoids churn during the change freeze.

Weeks 5 to 6, Nov 10 to Nov 23

Dry run promotions. Run a one day campaign on testnets for your stablecoin or in game currency to see if fee elastic demand overwhelms your systems. Track the difference between expected and realized fees under pressure.
Bridges: test optimistic and zero knowledge proof paths under back to back blob posts. Verify that watchers and challenge windows are not starved by higher throughput.
Consumer apps: ship a canary release to 5 percent of users that optimizes for larger, more frequent batches. Add a server side kill switch to revert batching thresholds if price conditions change.

Weeks 7 to 8, Nov 24 to Dec 7

Code freeze the week of November 24. Tag releases that you will ship to mainnet if testnet metrics hold.
Prepare the December 3 mainnet day plan. Assign owners for node upgrades, indexer migrations, and feature flag flips. Pre write status updates for success and for rollback.
On December 3, roll out feature flags that depend only on PeerDAS, not on increased blob counts. Aim for observable wins like faster postings and clearer fee breakdowns without changing user flows too much on day one.

Weeks 9 to 10, Dec 8 to Dec 21

After the first blob increase, measure your cost curves daily. If you hit your savings targets, pass some of it to users. For stablecoin apps, lower default fees or add a promotional free tier capped by transaction count.
Rollups: retune batch sizes and posting schedules to the new capacity. Publish a short postmortem of any propagation or orphan issues you saw during the first week.
Wallets: enable advanced settings that let power users choose between fastest post and cheapest post based on blob price bands.

Weeks 11 to 12, Dec 22 to Jan 4

Second blob increase window. Rerun your stress tests with holiday traffic models. Confirm that your guards, alerts, and auto routing work at the new capacity.
Games and consumer apps: ship the second wave of features that depend on cheaper data. Examples include larger item bundles, hourly settlement for creator payouts, or onchain session logs for customer support.

Week 13, Jan 5 to Jan 11

Consolidate. Clear on call rotations for the first week of January. Merge what worked into your long term defaults. Remove temporary logging that added overhead.
Publish a plain language summary to users that explains what changed, why fees moved, and what to expect next. Clarity builds trust and reduces churn.

Risks and how to handle them

Propagation under load. Higher blob counts can stress block propagation. Track orphan rates and consider relay settings that match your client’s behavior.
Price surprises. Supply increases, but demand is not static. Keep dynamic caps, alerts, and fallback routes in place through January.
Client diversity. Watch for client specific bugs. If you see issues isolated to Lighthouse, Prysm, Teku, or others, follow their release channels and hedge with a second client.
Indexers and explorers. More data is flowing. Make sure your explorers are ready to display larger batches and new fields tied to sampling.

The bottom line

Fusaka is not just another name in the roadmap. It is a practical unlock for builders who need cheaper, reliable data posting. PeerDAS lets the network check more while downloading less. Phased blob increases expand the lane for rollups to move. The combination does not promise instant miracles, it gives teams the raw materials to make better products. If you plan and ship through the next 90 days, you can meet December with lower fees, faster settlement, and a clearer path to growth in 2026.