Fusaka follows this year’s Pectra Upgradewhich represents a major advancement in Ethereum’s scaling roadmap that improves L1 performance, increases blob throughput, and improves user experience.
The Fusaka network upgrade is expected to activate on the Ethereum mainnet at the location 13,164,544 (December 3, 2025, 9:49:11 PM UTC). Fusaka also introduces Blob Parameter Only (BPO) forks to safely scale blob throughput after enabling PeerDAS. These are minimal, configuration-only upgrades that adjust the blob target/maximum and fee update fraction. See the activation table below for more details.
Fusaka mainnet client versions are listed below.
Presentation of Fusaka
Fusaka’s flagship feature is PeerDAS (Peer Data Availability Sampling), which enables significant blob throughput scaling. Fusaka also includes optimizations at the execution layer and consensus layer to scale L1 performance and improve user experience. This article describes the main improvements. For a more complete overview, see Ethereum.org Guide to Upgrading.
Blob scale
PeerDAS
EIP-7594 introduces PeerDAS, a new network protocol that allows nodes to check the availability of blob data by sampling rather than downloading entire blobs. This is a key step toward increasing blob throughput while maintaining the security and decentralization of Ethereum.
Since the Dencun upgradeLayer 2 usage has increased significantly, often reaching the current limit of 9 blobs per block. PeerDAS allows Ethereum to increase this limit without compromising security. It does this by using erasure coding to allow nodes to sample portions of blob data while cryptographically ensuring that the entire data is available on the network. This creates a path to higher blob targets outlined in the Ethereum guide. 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 grows beyond current limits, L2 transaction fees can further decrease while maintaining the security guarantees of data availability on Ethereum L1.
Once PeerDAS is enabled, Ethereum will use Blob Parameter Only (BPO) forks to safely increase blob throughput instead of consolidating blob parameter adjustments with named forks. Fusaka includes two planned adjustments to BPO settings on mainnet starting December 9, 2025. These BPOs will increase the target and maximum blobs per block from 6 and 9 respectively to 10 and 15 in BPO1 and 14 and 21 in BPO2. See the BPO Calendar below for more details.
L1 scale
ModExp optimization
EIP-7883 And EIP-7823 work together to optimize ModExp precompilation. EIP-7883 increases gas costs to more accurately reflect the complexity of the calculations, including increasing minimum gas costs and tripling general cost calculations. EIP-7823 sets upper limits for ModExp operations. Together, these changes ensure that resource-intensive crypto operations are properly priced and support potential future increases in block gas limits.
Transaction gas limit cap
EIP-7825 implements a protocol-level transaction gas cap limit of 16,777,216 gas, preventing individual transactions from consuming too much block gas and protecting against DoS attacks. This lays the foundation for parallel transaction processing in the EVM.
Network protocol optimization
EIP-7642 introduced eth/69, which removes pre-merge fields and Bloom receipt from the network protocol. This cleanup reduces synchronization bandwidth requirements, adds an explicit history streaming window for nodes to be advertised, and simplifies the codebase by removing legacy components that are no longer needed after the merge.
Increased gas limit
EIP-7935 increases Ethereum’s default gas limit to 60 million, reflecting the gas limit at which core developers believe Ethereum L1 can currently safely scale. This increase allows for greater L1 execution capacity and has been thoroughly tested on different client combinations to ensure network stability and security.
Improve the UX
secp256r1 Precompile
EIP-7951 adds native support for secp256r1 elliptic curve via new precompiled contract. This enables direct integration with modern secure hardware such as Apple Secure Enclave, Android Keystore and FIDO2/WebAuthn devices, reducing friction for mainstream blockchain adoption through familiar authentication flows.
Opcode Count leading zeros
EIP-7939 introduced 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 proof costs.
Fusaka Specifications
The full list of changes introduced to Fusaka can be found in EIP-7607. The main EIPs include:
Additional Support EIPs:
The full specifications for the execution and consensus layer changes are available in the following versions:
Fusaka also introduces changes to the engine API used for communication between consensus and execution layer nodes. These are specified in the Osaka execution-apis repository file.
Fusaka Activation
Fusaka network upgrade will activate on Ethereum mainnet at the start of the epoch 411392which will take place on December 3, 2025 at 21:49:11 UTC.
It was previously enabled on the Hoodi, Holesky and Sepolia test networks.
Fork Schedule with Blob Parameters Only (BPO)
After the main activation of Fusaka, the network will implement Blob Parameter Only forks to gradually increase blob throughput. BPO1 will increase the blob target per block to 10 and maximum to 15. BPO2 will further increase the target to 14 and maximum to 21.
Mainnet BPO Schedule
| BPO fork | Era | Date and time (UTC) | Unix Timestamp |
|---|---|---|---|
| BPO1 | 412672 | 2025-12-09 14:21:11 | 1765290071 |
| BPO2 | 419072 | 2026-01-07 01:01:11 | 1767747671 |
Client versions
The following client versions are suitable for upgrading Fusaka on the Ethereum mainnet.
Consensus Layer Posts
When running a validator, the Consensus Layer Beacon node and Validator client must be updated.
Execution layer versions
Tools
FAQs
How do Ethereum network upgrades work?
Ethereum network upgrades require explicit buy-in from node operators on the network. Even if client developers reach consensus on the EIPs included in an upgrade, they are not the ultimate decision makers of its adoption.
For the upgrade to go live, validators and non-staking nodes must manually update their software to support the introduced protocol changes.
If they are using an Ethereum client that is not updated to the latest version (listed above), at the fork block it will disconnect from the upgraded peers, leading to a fork on the network. In this scenario, each subset of nodes in the network will remain connected only to those that share their (un)upgraded status.
Although most Ethereum upgrades are not controversial and cases leading to forks are rare, the ability for node operators to coordinate on whether or not to support an upgrade is a key feature of Ethereum governance.
For a more comprehensive overview of Ethereum’s governance process, see this conference by Tim Beiko.
As an Ethereum mainnet user or ETH holder, do I need to do anything?
In short, no.
If you are using an exchange, digital wallet, or hardware wallet, you do not need to do anything unless your exchange or wallet provider asks you to take additional steps.
If you want to watch the live update, you can join the online viewing party!
As a non-staking node operator, what should I do?
To be compatible with the upgrade, update your node’s runtime and consensus layer clients to the versions listed in the table above.
As a staker, what should I do?
To be compatible with the upgrade, update your node’s runtime and consensus layer clients to the versions listed in the table above. Make sure your beacon node and validation client are updated.
As an application or tool developer, what should I do?
Review the EIP included in Fusaka to determine if and how they affect your project. The introduction of PeerDAS, support for secp256r1 and the new CLZ opcode provide exciting opportunities for improved features and performance optimizations. In particular, refer to this message for more information about changes to blob submission, and this message for more information on changes to the gas limit per transaction.
Why “Fusaka”?
Execution layer upgrades follow Devcon city names, and consensus layer upgrades use star names. “Fusaka” is the combination of Fulu, a star in the constellation Cassiopeia, and Osaka, where Devcon V is located.
