“`html
Fusaka aligns with this year’s Pectra enhancement, signifying a significant advancement in Ethereum’s scaling strategy by introducing PeerDAS along with critical enhancements that improve blob throughput, L1 efficiency, and user interaction.
This article reveals the testing network activation timetable for the initial three testnets, commencing with Holesky at slot 5,283,840 (October 1, 2025, 08:48:00 UTC). Refer to the activation schedule below for the full timelines for Sepolia and Hoodi. Fusaka also introduces Blob Parameter Only (BPO) forks to securely scale blob throughput following the activation of PeerDAS. These are minimal, configuration-only upgrades that modify the blob target/max and fee update fraction.
The Fusaka testnet client versions are detailed below. Once all three testnets have been upgraded successfully, a mainnet activation slot will be selected.
Fusaka Summary
Fusaka’s flagship EIP is PeerDAS (Peer Data Availability Sampling), which facilitates considerable blob throughput scaling. The upgrade additionally encompasses enhancements across execution and consensus layers to boost L1 performance and enrich user experience. This article outlines the key enhancements. For a more thorough overview, refer to ethereum.org’s overview of the upgrade.
Blob Scaling: PeerDAS
EIP-7594 presents PeerDAS, a novel networking protocol that permits nodes to verify the availability of blob data through sampling instead of downloading entire blobs. This is a pivotal move toward increased blob throughput while preserving Ethereum’s security and decentralization.
Following the Dencun upgrade, layer 2 usage has surged significantly, frequently reaching the current limitation of 9 blobs per block. PeerDAS empowers Ethereum to expand this limit without compromising security. It does this by employing erasure coding, enabling nodes to sample segments of blob data while still cryptographically ensuring that the complete data is accessible across the network. This paves the way for higher blob targets mentioned in Ethereum’s scaling plan.
This sampling methodology directly aids layer 2 rollups by facilitating higher blob throughput without proportionately escalating bandwidth demands for individual nodes. As blob capacity expands beyond current limitations, L2 transaction fees can further diminish while retaining the security assurances of data availability on Ethereum L1.
To safely boost blob throughput after the activation of PeerDAS, Ethereum will implement Blob-Parameter-Only (BPO) forks. Fusaka includes two scheduled BPO parameter modifications on Holesky starting October 7, 2025, with analogous schedules for other testnets. These BPOs will elevate the per-block blob target and maximum from 6 & 9 respectively to 10 & 15 in BPO1 and 14 & 21 in BPO2.
Boost L1
ModExp Enhancement
EIP-7883 and EIP-7823 collaborate to optimize the ModExp precompile. EIP-7883 raises gas fees to more accurately depict computational complexity, including increasing minimum gas costs and tripling general cost calculations. EIP-7823 establishes upper limits for ModExp operations. Collectively, these modifications ensure that resource-heavy cryptographic processes are properly priced and assist potential future increases in block gas limits.
Transaction Gas Limit Ceiling
EIP-7825 executes a protocol-level
“““html
transaction gas limit threshold of 16,777,216 gas, inhibiting individual transactions from utilizing an excessive block gas and safeguarding against DoS attacks. This establishes the foundation for concurrent transaction processing within the EVM.
Network Protocol Refinement
EIP-7642 presents eth/69, which eliminates pre-merge fields and the receipt Bloom from the network protocol. This streamlining minimizes synchronization bandwidth needs, introduces a clear history serving period for nodes to proclaim and optimizes the codebase by discarding outdated components that are no longer requisite post-merge.
Gas Limit Enhancement
EIP-7935 elevates Ethereum’s standard gas limit to 60MM, reflecting the gas limit that core developers believe Ethereum L1 can securely accommodate. This augmentation fosters increased L1 execution capability and has undergone extensive testing across various client combinations to guarantee network stability and security.
In addition to these performance enhancements, Fusaka further improves the user and developer interactions with several focused upgrades.
Enhance UX
secp256r1 Precompile
EIP-7951 incorporates indigenous support for the secp256r1 elliptic curve via a novel precompiled contract. This permits direct integration with contemporary secure hardware such as Apple Secure Enclave, Android Keystore, and FIDO2/WebAuthn devices, lessening friction for widespread blockchain acceptance through familiar authentication processes.
Count Leading Zeros Opcode
EIP-7939 presents the CLZ (Count Leading Zeros) opcode, offering a native, gas-efficient approach to execute essential bit-counting tasks. This addition supports mathematical activities, compression techniques, and post-quantum signature systems while lowering ZK proving expenses.
Fusaka Specifications
The exhaustive list of modifications instituted in Fusaka is available in EIP-7607. The principal EIPs encompass:
Additional supporting EIPs:
Comprehensive specifications for the execution and consensus layer adjustments can be found in the subsequent releases:
Fusaka also brings forth modifications to the Engine API employed for interaction between consensus and execution layer nodes. These are delineated in the osaka file of the execution-apis repository.
Fusaka Security
Security analysts can engage in the Fusaka audit competition to assist in identifying potential vulnerabilities prior to mainnet deployment.
Fusaka Activation
The Fusaka network upgrade is scheduled to activate on Holesky, Sepolia, and Hoodi testnets as follows:
“““html
| 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 stated, please be informed that Fusaka will be the final network enhancement launched on Holesky. It will be deactivated soon after the enhancement is applied to it.
Blob Parameter Only (BPO) Fork Schedule
Subsequent to the main Fusaka activation, the network will execute Blob Parameter Only forks to systematically enhance blob throughput. BPO1 will raise the per-block blob target and maximum to 10 & 15 respectively. BPO2 will further lift 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 Timetable
| 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 subsequent client releases are appropriate for the Fusaka upgrade on all three testnets. Additional versions will enable support on the mainnet. Once these are launched, a further announcement will be published on this blog.
Consensus Layer Holesky, Sepolia & Hoodi Releases
When operating a validator, both the Consensus Layer Beacon Node and the Validator Client require updates.
Note: Lodestar users must consistently utilize the most recent rc version showcased on their releases page.
Execution Layer Holesky, Sepolia & Hoodi Releases
FAQ
How do Ethereum network upgrades function
“““html
How do upgrades function?
Upgrades to the Ethereum network necessitate explicit consent from node operators on the network. Although client developers reach an agreement on which EIPs are part of an upgrade, they are not the final arbiters of its implementation.
For the upgrade to become active, validators and non-staking nodes must manually refresh their software to accommodate the protocol alterations being proposed.
If they utilize an Ethereum client that is not upgraded to the current version (as mentioned above), at the fork block, it will disconnect from the updated peers, resulting in a fork on the network. In this case, each group of the network nodes will only maintain connections with those who share their (un)updated status.
While the majority of Ethereum upgrades are non-controversial and instances resulting in forks have been infrequent, the capacity for node operators to collaborate on whether to endorse an upgrade is a significant aspect of Ethereum’s governance.
For a more detailed overview of Ethereum’s governance process, refer to this presentation by Tim Beiko.
As an Ethereum mainnet user or ETH holder, is there any action I should take?
In brief, no.
This notification exclusively concerns Ethereum testnets. A subsequent announcement will be issued regarding Fusaka’s activation on the Ethereum mainnet, but even then, Ethereum mainnet users and ETH holders are not anticipated to need to take any measures.
As a non-staking testnet node operator, what should I do?
To align with the upgrade on any of these testnets, refresh your node’s execution and consensus layer clients to the versions indicated in the table above.
As a testnet staker, what actions should I take?
To align with the upgrade on any of these testnets, refresh your node’s execution and consensus layer clients to the versions specified in the table above. Ensure that both your beacon node and validator client are upgraded.
As a non-testnet node operator or staker, what should I do?
Nothing at the moment. Additional announcements will follow regarding Fusaka’s launch on the mainnet.
As an application or tooling developer, what steps should I take?
Examine the EIPs incorporated in Fusaka to evaluate if and how they influence your project. The addition of PeerDAS, secp256r1 support, and the new CLZ opcode present exciting prospects for improved functionality and performance enhancements.
Why “Fusaka”?
Updates to the execution layer are named after Devcon city names, whereas those pertaining to the consensus layer utilize star names. “Fusaka” is a blend of Fulu, a star in the constellation of Cassiopeia, and Osaka, the site of Devcon V.
“`
