Fusaka mainnet: PeerDAS, BPO schedule and L1 scaling details

The Fusaka mainnet upgrade delivers a coordinated set of protocol changes to scale blobs, raise execution capacity, and improve cryptographic UX on Ethereum; node operators and developers should use the published activation epoch and the BPO schedule to prepare their environments.

What is the Fusaka mainnet upgrade and which features matter most?

Fusaka is a protocol update that follows Pectra and focuses on three pillars: higher blob throughput, executionlayer optimizations, and user experience improvements.

Most notable is PeerDAS (EIP9594), which enables data availability sampling to verify blobs without full downloads. Moreover, Fusaka packages multiple EIPs that together set limits, adjust gas accounting, and add native cryptographic primitives.

When will Fusaka activate on mainnet and what are the BPO milestones?

The Ethereum Foundation set the upgrade activation at the start of epoch 411392, which is 3 December 2025 at 21:49:11 UTC. The official announcement lists that Fusaka will be followed by two Blob Parameter Only (BPO) forks to raise blob capacity safely.

Specifically, the BPO schedule on mainnet is: BPO1 — Epoch 412672 — 2025-12-09 14:21:11 UTC — Unix 1765290071, and BPO2 — Epoch 419072 — 2026-01-07 01:01:11 UTC — Unix 1767747671. Consequently, the perblock blob target and maximum will move from 6 & 9 to 10 & 15 in BPO1 and then to 14 & 21 in BPO2.

How does the PeerDAS protocol change blob availability and L2 scaling?

PeerDAS (the peer das protocol) replaces fullblob downloads with sampling supported by erasure coding, letting nodes verify data availability probabilistically while preserving cryptographic guarantees.

That sampling model reduces pernode bandwidth demand, so layer-2 rollups can rely on higher blob targets without forcing every node to carry proportional traffic.

As a result, rollups should see a path to lower L2 fees and increased throughput as blob capacity rises. However, the upgrade introduces Blob Parameter Only forks so changes to targets and maximums occur in staged, configurable steps after PeerDAS activation.

How does sampling preserve security?

PeerDAS uses erasure coding so sampled fragments cryptographically imply full data availability across the network.

This design aims to maintain decentralisation by avoiding heavy bandwidth burdens on individual nodes while keeping proofs compact for validators and full nodes.

What is the expected impact on rollups?

Rollups will be able to submit more blob data per block as BPO steps occur, enabling larger L2 batches and potentially reducing pertx costs. Meanwhile, node operators benefit from bandwidth efficiency due to sampling, which lowers operational barriers for participation.

Which execution and consensus EIPs does Fusaka include and what do they change?

Fusaka aggregates a core set of EIPs (see EIP7607 for the full spec) that touch consensus, execution, networking, and gas accounting. Core EIPs listed in the announcement include: EIP7594 (PeerDAS), EIP7823 (upper bounds for ModExp), EIP7825 (transaction gas limit cap), EIP7883 (ModExp gas cost increase), EIP7917, EIP7918, EIP7934, EIP7939 (CLZ opcode), and EIP7951 (secp256r1 precompile support).

Supporting EIPs include EIP7642 (eth/69 network cleanup), EIP7892 (Blob Parameter Only hardforks), EIP7910 (eth_config JSONRPC), and EIP7935 (default gas limit to 60M). For full technical references, consult the published upgrade specification: EIP7607.

How are ModExp and gas costs adjusted?

Fusaka applies EIP7883 to increase ModExp gas costs so pricing better reflects computational complexity, including a higher minimal cost and a general cost multiplier.

At the same time, EIP7823 imposes upper bounds on ModExp operations to cap resource use. Together, these changes protect nodes from overly expensive cryptographic operations as block capacity grows.

What are the network and gaslimit changes?

EIP7642 adds eth/69 to remove premerge fields and the receipt Bloom, lowering sync bandwidth and simplifying history advertisement.

Importantly, EIP7825 introduces a pertransaction gas limit cap set at 16,777,216 gas, and EIP7935 raises the default block gas limit to 60,000,000 gas to enable higher L1 execution capacity.

Which clients and tooling must be updated for Fusaka mainnet?

The announcement lists consensus and execution client releases suitable for Fusaka. Consensus clients named include Grandine 2.0.0, Lighthouse 8.0.0, Lodestar 1.36.0, Nimbus 25.11.0, Teku 25.11.0, and Prysm (TBA). Execution clients include Besu 25.11.0, Erigon 3.2.2, goethereum 1.16.7, Reth 1.9.0, and Nethermind (TBA).

Additionally, tooling such as mevboost 1.10 and commitboost 0.9.2 are listed for compatibility. Validators must update both beacon nodes and validator clients to the released versions to avoid disconnection at the fork point.

What should users, operators and developers do ahead of Fusaka?

For most end users and ETH holders, no action is required; exchanges and wallets will communicate any specific steps. However, node operators and stakers must update both execution and consensus layer clients to the versions listed above and validate their signing infrastructure across the activation window.

Developers and tooling providers should review EIPs like EIP7594, EIP7951, and EIP7939 to identify integration opportunities – for example, native secp256r1 precompile support and the CLZ opcode can simplify hardware crypto integration and lower ZK proving costs. Indeed, careful testing on testnets mirrors the approach used during the Hoodi, Holesky, and Sepolia dress rehearsals.

All activation dates, epochs, EIP numbers, client versions and BPO timestamps are taken from the Ethereum Foundations Fusaka mainnet announcement and the Fusaka specification.

Review the client compatibility notes and mark maintenance windows around 3 December 2025.