Fusaka follows this year Spectra UpgradeThis represents significant progress in Ethereum’s scaling roadmap to improve L1 performance, increase blob throughput, and improve user experience.
The Fusaka network upgrade will be activated in an Ethereum mainnet slot. 13,164,544 (December 3, 2025, 21:49:11 UTC). Fusaka also introduced the Blob Parameter Only (BPO) fork to safely scale blob throughput after PeerDAS activation. This is a minimal configuration only upgrade that adjusts blob target/max and fee update rate. reference activation table See below for more details.
Fusaka mainnet client releases are listed. below.
face outline
A key feature of Fusaka is Peer Data Availability Sampling (PeerDAS), 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 key improvements. For a more comprehensive overview, see: Upgrade guide on ethereum.org.
scale blob
shipDAS
EIP-7594 We introduce PeerDAS, a new networking protocol that allows nodes to check blob data availability through sampling rather than downloading the entire blob. This is a key step toward scaling blob throughput while maintaining the security and decentralization of Ethereum.
since 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. 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 across the network. This creates a path towards the higher blob goals outlined in Ethereum. Expansion 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 expands beyond current limits, L2 transaction fees can be further reduced while maintaining security guarantees for data availability in Ethereum L1.
After PeerDAS is enabled, Ethereum uses Blob Parameter Only (BPO) forks to safely increase blob throughput, rather than tying blob parameter adjustments to named forks. Fusaka includes two planned BPO parameter adjustments to mainnet starting December 9, 2025. These BPOs increase the blob target and maximum per block from 6 and 9, respectively, to 10 and 15 in BPO1 and 14 and 21 in BPO2. reference BPO schedule See below for more details.
scale L1
ModExp Optimization
EIP-7883 and EIP-7823 We work together to optimize ModExp precompilation. EIP-7883 increases gas costs to more accurately reflect computational complexity, including increasing the minimum gas cost and tripling the typical cost calculation. EIP-7823 sets an upper limit on ModExp operations. These changes ensure that resource-intensive crypto operations are priced appropriately and support potential future block gas limit increases.
Transaction Gas Limit
EIP-7825 Implementing a protocol-level transaction gas limit of 16,777,216 gas prevents individual transactions from consuming excessive block gas and protects against DoS attacks. This lays the foundation for parallel transaction processing in EVM.
Network Protocol Optimization
EIP-7642 Introduces eth/69, which removes pre-merge fields and receipt Bloom from the networking protocol. This cleanup reduces synchronization bandwidth requirements, adds an explicit record serving window for nodes to advertise, and simplifies the code base by removing legacy components that are no longer needed after a merge.
Increased gas limit
EIP-7935 Increase 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 greater L1 execution capacity and has been thoroughly tested across a variety of client combinations to ensure network stability and security.
UX improvements
secp256r1 precompilation
EIP-7951 Add native support for secp256r1 elliptic curves via a new precompiled contract. This allows direct integration with modern security hardware such as Apple Secure Enclave, Android Keystore, and FIDO2/WebAuthn devices, reducing friction for mainstream blockchain adoption through familiar authentication flows.
Leading Zero Count Opcode
EIP-7939 We introduce the Count Leading Zeros (CLZ) opcode to provide a gas-efficient native way to perform basic bit counting operations. This additional feature supports mathematical operations, compression algorithms, and post-quantum signature schemes while reducing the cost of ZK proofs.
face specifications
A full list of changes introduced in Fusaka can be found here: EIP-7607. Core EIPs include:
Additional supported EIPs:
Full specifications for execution and consensus layer changes will be available in the next release.
Fusaka also introduced changes to the Engine API used for communication between consensus layer nodes and execution layer nodes. This is specified in the next item. osaka Execution API repository file.
face activation
The Fusaka network upgrade will be activated on the Ethereum mainnet at the start of the epoch. 411392Occurs on December 3, 2025 at 21:49:11 UTC.
Previously activated. Hoodie, Horseski, Sepolia Testnet.
BPO (Blob parameters only) fork schedule
Following the major activation of Fusaka, the network will gradually increase blob throughput by implementing a fork dedicated to blob parameters. BPO1 increases the blob target per block to 10 and the maximum to 15. BPO2 further increases the target to 14 and the maximum to 21.
Mainnet BPO Schedule
| BPO Fork | times | 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 next client release is eligible for the Fusaka upgrade on the 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
tooling
FAQ
How does the Ethereum network upgrade work?
Ethereum network upgrades require explicit consent from network node operators. Client developers have reached a consensus on which EIPs are included in the upgrade, but are not the final decision makers on their adoption.
For the upgrade to begin, 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 (listed above), it will lose connectivity with upgraded peers on the fork block, causing a fork in the network. In this scenario, each subset of network nodes maintains connections only with nodes that share the non-upgraded state.
Although most Ethereum upgrades are uncontroversial and rarely lead to forks, the option for node operators to adjust whether they support upgrades is a core feature of Ethereum governance.
For a more thorough overview of Ethereum’s governance process, see: Tim Beiko’s talk.
Is there anything I need to do as an Ethereum mainnet user or ETH holder?
Simply put, no.
If you use an exchange, digital wallet, or hardware wallet, you do not need to take any action unless you receive further instructions from the exchange or wallet provider.
To see the upgrade in real time: online watch party!
What do I need to do as a non-staking node operator?
To be compatible with the upgrade, update your node’s execution and consensus layer clients to the versions listed in the table above.
What should I do as a staker?
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 nodes and validator clients are updated.
What should I do as an application or tool developer?
examine EIP included in Fusaka Find out if and how it will affect your project. PeerDAS, secp256r1 support, and the introduction of new CLZ opcodes provide exciting opportunities for enhancements and performance optimizations. In particular, see: this post For more information about blob submission changes: this post For more information about changing gas limits per transaction, see here.
Why “anger”?
Upgrades to the execution layer use Devcon city names, while upgrades to the consensus layer use star names. Fusaka is a compound word of Osaka, the location of Fulu and Devcon V, stars in the constellation Cassiopeia.