Fusaka follows this year's Pectra upgrade, representing a major step forward in Ethereum's scaling roadmap by introducing PeerDAS and key improvements that enhance blob throughput, L1 performance, and user experience.
This post announces the testnet activation schedule for the first three testnets, beginning with Holesky at slot 5,283,840 (October 1, 2025, 08:48:00 UTC). See the activation table below for the complete Sepolia and Hoodi timeline. 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.
The Fusaka testnet client releases are listed below. Once all three testnets have successfully upgraded, a mainnet activation slot will be chosen.
Fusaka Overview
Fusaka's headlining EIP is PeerDAS (Peer Data Availability Sampling), which enables significant blob throughput scaling. The upgrade also includes optimizations across execution and consensus layers 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 complete 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.
To safely ramp blob throughput after PeerDAS is activated, Ethereum will use Blob-Parameter-Only (BPO) forks. Fusaka includes two planned BPO parameter adjustments on Holesky starting October 7, 2025, with similar schedules for other testnets. 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.
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 60MM, reflecting the gas limit that core developers believe Ethereum L1 can 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.
Beyond these performance improvements, Fusaka also enhances the user and developer experience with several targeted upgrades.
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:
- EIP-7594: PeerDAS - Peer Data Availability Sampling
- EIP-7823: Set upper bounds for MODEXP
- EIP-7825: Transaction Gas Limit Cap
- EIP-7883: ModExp Gas Cost Increase
- EIP-7917: Deterministic proposer lookahead
- EIP-7918: Blob base fee bounded by execution cost
- EIP-7934: RLP Execution Block Size Limit
- EIP-7939: Count leading zeros (CLZ) opcode
- EIP-7951: Precompile for secp256r1 Curve Support
Additional supporting EIPs:
- EIP-7892: Blob Parameter Only Hardforks
- EIP-7642: eth/69 - Drop pre-merge fields
- EIP-7910: eth_config JSON-RPC Method
- EIP-7935: Set default gas limit to 60M
Full specifications for the execution and consensus layer changes are available in the following releases:
- Execution layer: v2.18.0rc5.dev1
- Consensus layer: v1.6.0-beta.0
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 Security
Security researchers can participate in the Fusaka audit competition to help identify potential issues before mainnet deployment.
Fusaka Activation
The Fusaka network upgrade will activate on Holesky, Sepolia, and Hoodi testnets as follows:
| Network | Slot | UTC Time | UNIX Timestamp |
|---|---|---|---|
| Holesky | 5,283,840 | 2025-10-01 08:48:00 | 1759308480 |
| Sepolia | 8,724,480 | 2025-10-14 07:36:00 | 1760427360 |
| Hoodi | 1,622,016 | 2025-10-28 18:53:12 | 1761677592 |
As previously announced, note that Fusaka will be the last network upgrade deployed to Holesky. It will be shut down shortly after the upgrade has been deployed on it.
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 and maximum to 10 & 15 respectively. BPO2 will further increase the target to 14 and maximum to 21.
Holesky BPO Schedule
| BPO Fork | Epoch | Date & Time (UTC) | Unix Timestamp |
|---|---|---|---|
| BPO1 | 166,400 | 2025-10-07 01:20:00 | 1759800000 |
| BPO2 | 167,936 | 2025-10-13 21:10:24 | 1760389824 |
Sepolia BPO Schedule
| BPO Fork | Epoch | Date & Time (UTC) | Unix Timestamp |
|---|---|---|---|
| BPO1 | 274,176 | 2025-10-21 03:26:24 | 1761017184 |
| BPO2 | 275,712 | 2025-10-27 23:16:48 | 1761607008 |
Hoodi BPO Schedule
| BPO Fork | Epoch | Date & Time (UTC) | Unix Timestamp |
|---|---|---|---|
| BPO1 | 52,480 | 2025-11-05 18:02:00 | 1762365720 |
| BPO2 | 54,016 | 2025-11-12 13:52:24 | 1762955544 |
Client Releases
The following client releases are suitable for the Fusaka upgrade on all three testnets. Further versions will activate support on mainnet. Once these are released, another announcement will be made on this blog.
Consensus Layer Holesky, Sepolia & Hoodi Releases
When running a validator, both the Consensus Layer Beacon Node and Validator Client must be updated.
Execution Layer Holesky, Sepolia & Hoodi 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.
This announcement only pertains to Ethereum testnets. A further announcement will be made for Fusaka's activation on the Ethereum mainnet, but even then, Ethereum mainnet users and ETH holders are not expected to have to take action.
As a non-staking testnet node operator, what do I need to do?
To be compatible with the upgrade on any of these testnets, update your node's execution and consensus layer clients to the versions listed in the table above.
As a testnet staker, what do I need to do?
To be compatible with the upgrade on any of these testnets, 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 a non-testnet node operator or staker, what do I need to do?
Nothing for now. Further announcements will be made for Fusaka's activation on mainnet.
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.
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.