Fusaka follows this year’s Pectra upgrade, representing a major step forward in Ethereum’s scaling roadmap that improves L1 performance, increases blob throughput, and enhances user experience.
The Fusaka network upgrade is scheduled to activate on the Ethereum mainnet at slot 13,164,544 (December 3, 2025, 21:49:11 UTC). Fusaka also introduces Blob Parameter Only (BPO) forks to safely scale blob throughput after PeerDAS activation. These are minimal, config-only upgrades that adjust the blob target/max and fee update fraction. See the activation table below for further details.
The Fusaka mainnet client releases are listed below.
Fusaka Overview
Fusaka’s headlining feature is PeerDAS (Peer Data Availability Sampling), which enables significant blob throughput scaling. Fusaka also includes optimizations across the execution layer and consensus layer to scale L1 performance and improve user experience. This post outlines the major improvements. For a more comprehensive overview, see ethereum.org’s guide to the upgrade.
Scale Blobs
PeerDAS
EIP-7594 introduces PeerDAS, a new networking protocol that allows nodes to verify blob data availability through sampling rather than downloading entire blobs. This is a key step toward scaling blob throughput while maintaining Ethereum’s security and decentralization.
Since the Dencun upgrade, layer 2 usage has grown substantially, often reaching the current 9 blob per block limit. PeerDAS allows Ethereum to increase this limit without compromising on security. It does so by using erasure coding to allow nodes to sample portions of blob data while still cryptographically guaranteeing that the full data is available across the network. This creates a path toward higher blob targets outlined in Ethereum’s scaling roadmap.
This sampling approach directly benefits layer 2 rollups by supporting higher blob throughput without proportionally increasing bandwidth requirements for individual nodes. As blob capacity scales beyond current limits, L2 transaction fees can decrease further while maintaining the security guarantees of data availability on Ethereum L1.
After PeerDAS is activated, Ethereum will use Blob Parameter Only (BPO) forks in order to safely increase blob throughput instead of bundling the blob parameter adjustments with named forks. Fusaka includes two planned BPO parameter adjustments on mainnet starting December 9, 2025. These BPOs will raise the per-block blob target and maximum from 6 & 9 respectively to 10 & 15 in BPO1 and 14 & 21 in BPO2. See the BPO schedule below for further details.
Scale L1
ModExp Optimization
EIP-7883 and EIP-7823 work together to optimize the ModExp precompile. EIP-7883 increases gas costs to more accurately reflect computational complexity, including raising minimal gas costs and tripling general cost calculations. EIP-7823 sets upper bounds for ModExp operations. Together, these changes ensure that resource-intensive cryptographic operations are properly priced and support potential future block gas limit increases.
Transaction Gas Limit Cap
EIP-7825 implements a protocol-level transaction gas limit cap of 16,777,216 gas, preventing individual transactions from consuming excessive block gas and protecting against DoS attacks. This lays the groundwork for parallel transaction processing in the EVM.
Network Protocol Optimization
EIP-7642 introduces eth/69, which removes pre-merge fields and the receipt Bloom from the networking protocol. This cleanup reduces sync bandwidth requirements, adds an explicit history serving window for nodes to advertise, and simplifies the codebase by removing legacy components that are no longer needed post-merge.
Gas Limit Increase
EIP-7935 raises Ethereum’s default gas limit to 60M, reflecting the gas limit that core developers believe Ethereum L1 can currently safely scale to. This increase enables more L1 execution capacity and has been thoroughly tested across different client combinations to ensure network stability and security.
Improve UX
secp256r1 Precompile
EIP-7951 adds native support for the secp256r1 elliptic curve through a new precompiled contract. This enables direct integration with modern secure hardware like Apple Secure Enclave, Android Keystore, and FIDO2/WebAuthn devices, reducing friction for mainstream blockchain adoption through familiar authentication flows.
Count Leading Zeros Opcode
EIP-7939 introduces the CLZ (Count Leading Zeros) opcode, providing a native, gas-efficient way to perform fundamental bit-counting operations. This addition supports mathematical operations, compression algorithms, and post-quantum signature schemes while reducing ZK proving costs.
Fusaka Specifications
The complete list of changes introduced in Fusaka can be found in EIP-7607. The core EIPs include:
Additional supporting EIPs:
Full specifications for the execution and consensus layer changes are available in the following releases:
Fusaka also introduces changes to the Engine API used for communication between consensus and execution layer nodes. These are specified in the osaka file of the execution-apis repository.
Fusaka Activation
The Fusaka network upgrade will activate on the Ethereum mainnet at the start of epoch 411392, happening on December 3, 2025 at 21:49:11 UTC.
It was previously activated on the Hoodi, Holesky, and Sepolia testnets.
Blob Parameter Only (BPO) Fork Schedule
Following the main Fusaka activation, the network will implement Blob Parameter Only forks to gradually increase blob throughput. BPO1 will increase the per-block blob target to 10 and maximum to 15. BPO2 will further increase the target to 14 and maximum to 21.
Mainnet BPO Schedule
| BPO Fork | Epoch | Date & Time (UTC) | Unix Timestamp |
|---|---|---|---|
| BPO1 | 412672 | 2025-12-09 14:21:11 | 1765290071 |
| BPO2 | 419072 | 2026-01-07 01:01:11 | 1767747671 |
Client Releases
The following client releases are suitable for the Fusaka upgrade on the Ethereum mainnet.
Consensus Layer Releases
When running a validator, both the Consensus Layer Beacon Node and Validator Client must be updated.
Execution Layer Releases
Tooling
FAQ
How do Ethereum network upgrades work?
Ethereum network upgrades require explicit opt-in from node operators on the network. While client developers come to consensus on what EIPs are included in an upgrade, they are not the ultimate deciders of its adoption.
For the upgrade to go live, validators and non-staking nodes must manually update their software to support the protocol changes being introduced.
If they use an Ethereum client that is not updated to the latest version (listed above), at the fork block, it will disconnect from upgraded peers, leading to a fork on the network. In this scenario, each subset of the network nodes will only stay connected with those who share their (un)upgraded status.
While most Ethereum upgrades are non-contentious and cases leading to forks have been rare, the option for node operators to coordinate on whether to support an upgrade or not is a key feature of Ethereum’s governance.
For a more exhaustive overview of Ethereum’s governance process, see this talk by Tim Beiko.
As an Ethereum mainnet user or ETH holder, is there anything I need to do?
In short, no.
If you use an exchange, digital wallet or hardware wallet you do not need to do anything unless you are informed to take additional steps by your exchange or wallet provider.
If you’d like to watch the upgrade go live, you can join the online viewing party!
As a non-staking node operator, what do I need to do?
To be compatible with the upgrade, update your node’s execution and consensus layer clients to the versions listed in the table above.
As a staker, what do I need to do?
To be compatible with the upgrade, update your node’s execution and consensus layer clients to the versions listed in the table above. Make sure both your beacon node and validator client are updated.
As an application or tooling developer, what should I do?
Review the EIPs included in Fusaka to determine if and how they affect your project. The introduction of PeerDAS, secp256r1 support, and the new CLZ opcode offer exciting opportunities for enhanced functionality and performance optimizations. In particular, refer to this post for further info on blob submission changes, and this post for further info on changes to per-transaction gas limit.
Why “Fusaka”?
Upgrades to the execution layer follow Devcon city names, and those to the consensus layer use star names. “Fusaka” is the combination of Fulu, a star in the constellation of Cassiopeia, and Osaka, the location of Devcon V.
