Ethereum locks Dec 3 for Fusaka as PeerDAS cuts L2 fees

Breaking: Fusaka is locked for December 3

Ethereum’s core developers have locked the Fusaka network upgrade for December 3, 2025. The headline feature is Peer Data Availability Sampling, or PeerDAS, which changes how the network proves that data posted by rollups is actually available. PeerDAS is included as EIP‑7594 and has been tested across multiple devnets and public testnets, with client teams coordinating to ship a stable release on mainnet. For a plain‑English description and the formal specification, see the authors’ write‑up on the PeerDAS EIP‑7594 specification.

Fusaka also introduces a new way to scale blob capacity after activation. Rather than cram every change into a single fork, Ethereum will apply small, targeted increases called Blob Parameter Only forks. These BPO steps raise the number of blobs per block in phases, with monitoring between each step. The protocol team’s overview explains why this path lets the network scale blobs safely and steadily in the weeks after Fusaka goes live. Read the summary in Protocol Update 002 on scaling blobs.

PeerDAS in plain English

Think of a rollup batch as a very large photo. Today, most nodes have to download the entire photo to check that it exists on the network. PeerDAS lets nodes sample a few thin slices from across the photo and still be confident the whole image is available. How does that work?

• Rollups post their data as blobs, which live next to blocks and are optimized for cheap, temporary storage.
• PeerDAS applies an erasure coding technique. The original data is extended with extra information so that if you know enough small slices from across the data, you can mathematically infer that the rest must exist.
• Each node pulls only a small fraction of slices. With current parameters, a node needs roughly one eighth of the data for a local availability check, with room to lower that fraction later.
• The slices are checked against cryptographic commitments included in the block. If the slices verify, the node treats the blob as available without touching the whole blob.

The result is straightforward. Nodes no longer need to download every byte of every blob in every block. Bandwidth and disk pressure stay in check as total blob count rises, unlocking higher throughput without forcing operators to upgrade hardware.

Why this should push rollup fees from dollars to cents

Rollup users pay for two things: computation and storage on the rollup itself, and data availability on Ethereum. The second component dominates when rollups post large batches as blob data.

Blob pricing follows a supply and demand curve, similar to the EIP‑1559 base fee for gas. When blob space is scarce, the blob base fee rises. When blob space grows and demand stays the same, the base fee falls.

PeerDAS does two things at once:

1. It lowers the cost for the network to carry more blob data by reducing node bandwidth needs, enabling safe increases to per‑block blob limits.
2. It enables the BPO sequence, which increments blob capacity in the weeks after Fusaka. The first step lifts target and maximum blobs per block from today’s 6 and 9 to around 10 and 15. The second step raises that again to about 14 and 21. Timings are phased so operators can monitor performance between steps.

If blob supply roughly doubles or triples while demand is steady, the clearing price for blob space falls. Think of a congested highway adding lanes: fewer cars per lane, fewer slowdowns. In fee terms, batches that cost several dollars at peak can fall to the tens of cents or even single‑digit cents when the network has more headroom.

Here is a concrete mental model. Suppose a rollup typically posts a 512 kilobyte batch. If base blob demand had been pushing near the 9‑blob ceiling, the rollup often paid a spiky base fee. After the first BPO step, the ceiling rises and spikes flatten. After the second step, spikes flatten further. The rollup can also adjust batch size and cadence to the new equilibrium, posting more frequently at lower cost. Users see the effect as lower per‑transaction fees.

What users and builders will feel over the next 30, 60, and 90 days

Time zero is Wednesday, December 3, 2025, when Fusaka activates on mainnet. Here is a realistic timeline for what changes on the ground.

• Day 1 to Day 30

  • Sequencers update posting logic to take advantage of PeerDAS and the new conditions. Some will shift to more frequent but smaller batches. Others will keep batch size and change timing. Users should notice steadier fees with fewer sharp spikes.
  • The first BPO step lands within a couple of weeks. Blob target and maximum rise to roughly 10 and 15. Blob base fees fall during normal hours. Peak hours still see volatility, but peaks are lower.
  • Wallets that route across multiple rollups provide more predictable quotes. Bridges and onramps see fewer outlier costs when they batch transfers.

• Day 31 to Day 60

  • The second BPO step activates in early January. The network raises blob target and maximum again, to around 14 and 21. Rollups update parameters a second time.
  • Developers ship features assuming sub‑ten‑cent fees on major rollups. Expect subscriptions and micro‑transactions to appear in consumer wallets. Games re‑enable in‑session minting.
  • Tooling providers add PeerDAS metrics to dashboards so teams can watch sampling health and custody coverage. Operators update alerts for bandwidth and peer counts.

• Day 61 to Day 90

  • Fee patterns stabilize at the new capacity. Batch auction houses and intent solvers factor in lower data costs, so cross‑rollup swaps get tighter quotes.
  • A wave of products ships with bundled actions. Instead of four separate clicks for approve, swap, bridge, and stake, users see a single action executed atomically.
  • Teams start planning for further capacity increases later in 2026 as client bandwidth optimizations and PeerDAS parameter tuning continue.

As fees fall and UX improves, keep an eye on regulatory and market tailwinds like the recent shift toward CFTC and SEC unlock trading, which can amplify mainstream adoption.

Likely winners

• Base and the OP Stack family. Lower and steadier blob posting costs let these chains route more activity without punishing spikes. Coinbase’s consumer funnel, Optimism’s shared sequencer roadmap, and growing app‑chains in the stack all benefit.
• Arbitrum. Nitro’s large‑batch strategy benefits directly from cheaper blob space, keeping complex interactions cost efficient when data availability is abundant.
• Major zero‑knowledge rollups. zkSync, Starknet, Scroll, Linea, and Polygon’s zkEVM rely on publishing proof data and state diffs. Even if proof costs matter, cheaper data availability takes pressure off end user fees. For context on base layer progress, see how L1 zkEVM is moving to reality.
• Payments and commerce rails. Stablecoin onramps, checkout providers, and point‑of‑sale integrations become viable on more rollups when the marginal fee is a few cents. This dovetails with our onchain dollars go retail analysis.
• Intents and bundlers. Systems that package many small user intents into one onchain settlement benefit from lower data costs, allowing more frequent batching without reigniting fee spikes.

New UX patterns that become practical

• Bundled actions. A wallet presents one action while batching several onchain steps behind the scenes. With negligible extra call data, teams can design for clarity rather than fee minimization.
• Subscriptions that settle onchain. A few cents per period makes weekly or monthly pulls feasible directly on a rollup. Merchants can reconcile onchain without painful overhead.
• Micro‑payments and streams. Tipping, per‑article access, per‑level game unlocks, and pay‑as‑you‑go APIs become viable across more geographies. Wallets can expose obvious controls like spend caps and pausing.
• Sponsored transactions at scale. With lower posting costs, paymasters can subsidize more actions for trials, freemium tiers, and gasless onboarding.
• Richer in‑app confirmations. Designers can add context and safety checks at the cost of a few extra bytes, removing the excuse to cut safety corners.

Operational risks to watch

• Centralization pressure from bandwidth. Even with sampling, total throughput rises. Operators with weak connections could drop out. Client teams will publish recommended peer counts and gossip settings. Track bandwidth and adjust.
• Validator custody churn. PeerDAS includes a light custody requirement for validators that scales with validator count. It improves resilience but adds new operational duties. Monitor custody metrics to avoid silent performance loss.
• MEV side effects. More data and larger batches can change arbitrage and sandwich dynamics. Builders processing bigger rollup posts may see more revenue, tilting order flow toward high‑bandwidth builders. Watch concentration and adapt relay policies.
• Rollup batch timing shifts. With cheaper blobs, sequencers may post more often. That changes the cadence of oracles, withdrawals, and cross‑rollup settlement. Make assumptions explicit and code for variability.
• Parameter whiplash. Two BPO steps in quick succession require discipline. Operators who miss a release or forget to flip a flag can drift out of sync. Rehearse on staging and set calendar alarms.

Concrete examples: the dollars to cents shift

• A mint on a consumer rollup that cost 1.50 dollars at peak can fall to 20 to 30 cents when blob supply doubles and demand holds steady. If capacity rises again and batching improves, the same mint can land under 10 cents.
• A cross‑rollup swap that carried a wide quote because the solver priced in a spiky blob fee can tighten noticeably. The solver can post a settlement batch sooner without eating a fee spike.
• A small game that paused onchain item drops during congestion can re‑enable them. The mint happens when the sequencer’s batch hits the next low‑fee window, which occurs more often as blob space becomes less scarce.

These examples assume present demand and current compression levels. If demand surges, fees can still rise. The important change is that capacity is finally moving faster than demand grows, and the network has a mechanism to nudge it up.

What else ships in Fusaka that affects UX

A notable change is a per‑transaction gas limit cap around 16.7 million gas. This prevents a single transaction from swallowing a whole block and helps pack blocks more efficiently. Most users are unaffected because typical transactions are far below the cap, but batch deployers and heavy scripts should check their flows. The cap makes bundled actions more predictable and reduces worst‑case scenarios during peak hours.

A pragmatic checklist for wallets and dapps

Be ready to capture the drop on day one. Here is a short, practical list.

• Update clients and providers

  • Pin to client versions that include Fusaka and the preprogrammed BPO schedule. Verify execution and consensus endpoints expose PeerDAS and blob metrics.
  • Add health checks for peer counts, gossip bandwidth, and custody coverage. Alert when peers or sampling success dip.

• Rethink fees and routing

  • Lower default max fee and priority fee presets on rollups where you route transactions. Let routers favor chains with lower and steadier blob fees.
  • Expand your routing universe. Add a second or third rollup for features now that costs are predictable.

• Ship UX that assumes cents, not dollars

  • Turn on bundled actions by default. Replace multi‑step flows with one action where safe.
  • Enable onchain subscriptions with clear pause and cap controls. Start with weekly or monthly cadences and measure churn.
  • Add tipping and micro‑purchases where it makes sense. Use simple round numbers like 5 to 25 cents.

• Protect users during the transition

  • Add safety rails against stale assumptions. If your app assumed a batch every X minutes, move that to a config and surface it in logs.
  • Build fallbacks for temporary volatility during each BPO step. For example, retry posting during the next block if blob base fee exceeds a threshold.

• Measure and iterate

  • Instrument costs per action and success rates before and after each BPO step. Publish a lightweight dashboard so product teams can react quickly.
  • Run A/B tests with more frequent settlement now that it is cheaper. Track user satisfaction and slippage.

The bottom line

Fusaka is a carefully engineered opening of the faucet. PeerDAS lets the network carry more rollup data without overwhelming nodes, and BPO steps raise capacity in measured increments. The practical effect is that onchain actions priced for enthusiasts become affordable for everyone.

Teams that prepare will feel the change early. By updating clients, relaxing fee presets, and shipping features that thrive on low costs, builders can meet users where they are. Over the next 90 days, the network should replace fee spikes with smoother curves. That creates room for new habits, from subscriptions to streaming to one‑click bundles. Treat fees as a design input, not a constraint, and build the product you wanted to ship all along.