Fusaka continues this year pectra upgradeThis represents a major step forward in Ethereum’s scaling roadmap to improve L1 performance, increase blob throughput, and improve user experience.
Fusaka network upgrade scheduled to be activated on Ethereum mainnet slots 13,164,544 (December 3, 2025, 21:49:11 UTC). Fusaka also introduces a Blob Parameter Only (BPO) fork to safely scale Blob throughput after PeerDAS activation. These are minimal configuration upgrades that adjust blob targets/maximum and pricing updates. Please refer to activation table See below for more details.
Fusaka mainnet client releases listed below.
Overview of Fusaka
Fusaka’s star feature is PeerDAS (Peer Data Availability Sampling), which enables significant BLOB throughput scaling. Fusaka also includes optimizations across the execution and consensus layers to scale L1 performance and improve user experience. This post outlines the main improvements. For a more comprehensive overview, see . ethereum.org upgrade guide.
scale blob
PeerDAS
EIP-7594 PeerDAS is a new network protocol that allows nodes to verify the availability of BLOB data through sampling rather than downloading the entire BLOB. This is an important step in scaling BLOB throughput while maintaining Ethereum’s security and decentralization.
Since then, Denkun 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. This is achieved by using erasure coding to allow nodes to sample portions of the BLOB data while cryptographically guaranteeing that the complete data is available throughout the network. This creates a path to the higher BLOB targets mentioned in the Ethereum overview. Scaling roadmap.
This sampling approach directly benefits Layer 2 rollups by supporting higher BLOB throughput without proportionally increasing the bandwidth requirements of individual nodes. As BLOB capacity expands beyond its current limits, L2 transaction fees could be further reduced while maintaining the security guarantees of data availability on Ethereum L1.
Once PeerDAS is activated, Ethereum uses Blob Parameters Only (BPO) forks to safely increase Blob throughput, instead of bundling Blob parameter adjustments into named forks. Fusaka includes two BPO parameter adjustments scheduled for mainnet starting December 9, 2025. These BPOs increase the blob per block goal and maximum from 6 and 9 respectively to 10 and 15 in BPO1 and 14 and 21 in BPO2. Please refer to BPO schedule See below for more details.
scale L1
ModExp optimization
EIP-7883 and EIP-7823 Work together to optimize ModExp precompilation. EIP-7883 increases gas costs to more accurately reflect computational complexity. This includes minimal gas cost increases and a three-fold increase in general cost calculations. EIP-7823 sets an upper limit for ModExp operations. These changes ensure that resource-intensive crypto operations are priced appropriately and support the possibility of increasing block gas limits in the future.
transaction gas limit cap
EIP-7825 Implements a protocol-level transaction gas limit of 16,777,216 gas to prevent individual transactions from consuming excessive block gas and protect against DoS attacks. This lays the foundation for parallel transaction processing in EVM.
Network protocol optimization
EIP-7642 eth/69 is introduced, removing pre-merge fields and incoming blooms from networking protocols. This cleanup reduces synchronization 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 after the merge.
Increased gas limit
EIP-7935 This increases Ethereum’s default gas limit to 60M, reflecting the gas limit that core developers believe Ethereum L1 can currently safely scale to. This increase improves L1 execution capabilities and has been thoroughly tested across a variety of client combinations to ensure network stability and security.
Improved UX
secp256r1 precompile
EIP-7951 Add native support for secp256r1 elliptic curves through new precompiled contracts. This enables direct integration with modern secure hardware such as Apple Secure Enclave, Android Keystore, and FIDO2/WebAuthn devices, reducing the friction of mainstream blockchain adoption through familiar authentication flows.
Opcode to count leading zeros
EIP-7939 Introduces the CLZ (Count Leading Zeros) opcode, providing a native and gas-efficient way to perform basic bit counting operations. This addition supports mathematical operations, compression algorithms, and post-quantum signature schemes while reducing ZK proof costs.
Fusaka specification
A complete list of changes introduced in Fusaka can be found here: EIP-7607. Core EIP includes:
Additional support EIP:
Complete specifications for execution and consensus layer changes will be available in the next release.
Fusaka also introduces changes to the engine API used for communication between consensus layer nodes and execution layer nodes. these are, Osaka Execution API repository files.
fusaka activation
The Fusaka network upgrade will be enabled on Ethereum mainnet at the start of the epoch. 411392happens on December 3, 2025 at 21:49:11 UTC.
was previously activated Hoodie, Holesky, Sepolia testnet.
BLOB parameters only (BPO) fork schedule
Following Fusaka’s main activation, the network will implement a BLOB parameter-only fork to gradually increase BLOB throughput. BPO1 increases BLOB targets per block to 10, up to 15. BPO2 further increases the targets to 14 and up to 21.
Mainnet BPO schedule
| BPO fork | epoch | 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 release
The following client releases are suitable for Fusaka upgrades on Ethereum mainnet.
Consensus layer release
When running a validator, both the consensus layer beacon node and the validator client must be updated.
Execution layer release
touring
FAQ
How do Ethereum network upgrades work?
Upgrades to the Ethereum network require explicit opt-in from node operators on the network. Client developers reach agreement on which EIPs are included in the upgrade, but are not the final arbiter of deployment.
For the upgrade to take effect, validators and non-staking nodes will need to manually update their software to support the protocol changes being introduced.
If you are using an Ethereum client that has not been updated to the latest version (above), you will be disconnected from the upgraded peer at the fork block and a fork will occur on the network. In this scenario, each subset of network nodes maintains connectivity only with nodes that share the (un)upgraded status.
Although most Ethereum upgrades are uncontroversial and cases that lead to forks are rare, the option for node operators to adjust whether they support upgrades is an important feature of Ethereum’s governance.
For a more comprehensive overview of Ethereum’s governance process, please see. This talk 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 tells you to take additional steps.
If you would like to see the upgrade in action, please join us at the link below. Online viewing party!
What do I need to do as a non-staking node operator?
To be compatible with the upgrade, update your nodes’ execution and consensus layer clients to the versions listed in the table above.
What do I need to do as a staker?
To be compatible with the upgrade, update your nodes’ execution and consensus layer clients to the versions listed in the table above. Make sure that both your beacon node and validator client are updated.
What should an application or tool developer do?
Please check EIP included in Fusaka Determine if and how they will affect your project. The introduction of PeerDAS, secp256r1 support, and the new CLZ opcode provides great opportunities for enhanced functionality and performance optimization. In particular, see: this post For more information about changing BLOB submissions, see this post Learn more about changing per-transaction gas limits.
Why “Fusaka”?
Upgrades to the execution layer follow Devcon city names, and upgrades to the consensus layer use star names. “Fusaka” is a combination of the star “Fulu” in the Cassiopeia constellation and “Osaka”, the venue of Devcon V.
