Fusaka continues this year Pectra Upgraderepresents a major advance in Ethereum’s scaling roadmap by introducing key improvements to Peerdas and BLOB throughput, L1 performance and user experience.
In this post, we have announced the testnet activation schedule for the first three testnets. 5,283,840 (October 1, 2025, 08:48:00 UTC). Please see Activation Table Below is a complete Sepolia and Hoodie timeline. Fusaka also introduces a BLOB Parameter Only (BPO) fork to safely scale the BLOB throughput after Peerdas activation. These are minimal configuration only upgrades that adjust the BLOB target/max and rate update fractions.
Fusaka TestNet client releases are listed Below. Once all three testnets have been successfully upgraded, the mainnet activation slot is selected.
Fusaka Overview
Fusaka’s headline EIP is Peerdas (peer data availability sampling), which allows for critical blob throughput scaling. The upgrade also includes optimizations across the execution layer and consensus layer to scale L1 performance and improve the user experience. This post outlines the major improvements. See for a more comprehensive overview ethereum.org Upgrade Guide.
Scale blob: Peerdas
EIP-7594 Instead of downloading the full blob, Nodes introduces Peerdas, a new network protocol that allows you to check the availability of blob data through sampling. This is a critical step to scaling blob throughput while maintaining Ethereum’s security and decentralization.
Since Dencun UpgradeLayer 2 usage increases significantly, often reaching the current 9 blobs per block. Peerdas allows Ethereum to increase this limit without compromising security. This is done using erase coding to encrypt and ensure that complete data is available across the network, while allowing nodes to sample portions of BLOB data. This creates a path to a higher blob target that outlines Ethereum Scaling Roadmap.
This sampling approach directly benefits layer 2 rollup by supporting higher blob throughput without increasing the bandwidth requirements of individual nodes proportionally. L2 trading fees could drop even further as BLOB capacity scales beyond current limits.
To safely ramp blob throughput after Peerdas is active, Ethereum uses a Blob-Parameter only (BPO) fork. Fusaka includes two planned BPO parameter adjustments for Holesky from October 7, 2025, with similar schedules for other testnets as well. These BPOs increase the BLOB targets per block from 6 and 9, respectively, to 10 and 15 in BPO1 and 14 and 21 in BPO2.
Scale L1
Optimizing ModExp
EIP-7883 and EIP-7823 Work together to optimize ModExp Precompile. EIP-7883 increases the complexity of the calculation more accurately reflects gas costs. The EIP-7823 sets the upper limit of ModExp operations. Together, these changes ensure that resource-intensive encryption operations are properly priced and support the potential future increased block gas limits.
Transaction Gas Limit Cap
EIP-7825 Implements a protocol-level transaction gas limit cap of 16,777,216 gas to prevent individual transactions from consuming excessive blocking gas and protecting against DOS attacks. This is the basis for parallel transaction processing in EVM.
Optimizing Network Protocols
EIP-7642 Introducing ETH/69 to remove pre-merge fields and receipt blooms from the networking protocol. This cleanup simplifies the codebase by reducing the sync bandwidth requirements and adding an explicit history window for nodes and removing unnecessary legacy components after registration.
Increased gas limit
EIP-7935 It raises the default gas limit for Ethereum to 60mm, reflecting the gas limits that core developers believe the Ethereum L1 can safely scale. This increase allows for more L1 execution capabilities and is thoroughly tested with a variety of client combinations to ensure network stability and security.
Beyond these performance improvements, Fusaka enhances the user and developer experience with several target upgrades.
Improve UX
SECP256R1 Precompilation
EIP-7951 Adds native support for SECP256R1 elliptic curves through a new precompiled agreement. This allows direct integration with modern secure hardware such as Apple Secure Enclave, Android Keystore, and FIDO2/WebAuthn devices, reducing friction in mainstream blockchain adoption through familiar authentication flows.
Count the major Zeros OpCodes
EIP-7939 It introduces CLZ (count reading zero) opcodes to provide a native, gas-efficient way to perform basic bit count operations. This addition supports mathematical operations, compression algorithms, and quarterly signature schemes, while reducing ZK proof costs.
Fusaka specification
The complete list of changes introduced in Fusaka is EIP-7607. The core EIP includes:
Additional Support EIP:
The full specifications for execution and consensus layer changes are available in the next release.
Fusaka is also introducing changes to the engine API used for communication between consensus and execution layer nodes. These are specified in Osaka Run – APIS Repository File.
Fusaka Security
Security researchers can participate Fusaka Audit Competition It helps you identify potential issues before the mainnet is deployed.
Activation of Fusaka
Fusaka Network upgrades are active in 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 |
| Hoodie | 1,622,016 | 2025-10-28 18:53:12 | 1761677592 |
As previously announcedNote that Fusaka will be the last network upgrade deployed to Holesky. It will be shut down immediately after the upgrade is deployed.
BLOB Parameters Only (BPO) Fork Schedule
Following the activation of the main Fusaka, the network implements only the BLOB parameters, gradually increasing the BLOB throughput. BPO1 increases the BLOB targets per block to 10 and 15 respectively. BPO2 will increase the target to another 14, up to 21.
Holesky BPO Schedule
| BPO Fork | epoch | Date and 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 and Time (UTC) | Unix timestamp |
|---|---|---|---|
| BPO1 | 274,176 | 2025-10-21 03:26:24 | 1761017184 |
| BPO2 | 275,712 | 2025-10-27 23:16:48 | 1761607008 |
Hoodie BPO Schedule
| BPO Fork | epoch | Date and 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 Release
The following client releases are suitable for upgrades to Fusaka 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 the validator client must be updated.
Note: Lodestar users should always be up to date RC Versions listed in them (Release) Page.
Run layer Holesky, Sepolia & Hoodi releases
FAQ
How does an Ethereum Network upgrade work?
Upgrading an Ethereum Network requires explicit opt-in from a node operator on the network. The client developer is a consensus about the EIPS included in the upgrade, but is not the ultimate decision maker of adoption.
For the upgrade to live, validators and non-staking nodes must manually update the software to support changes to the protocols being deployed.
Using an Ethereum client that has not been updated to the latest version (above above) with a forkblock will disconnect from the upgraded peer and lead to a fork on the network. In this scenario, each subset of network nodes remains connected only to those who share the (UN) upgraded status.
Most Ethereum upgrades are not continuous and are rarely linked to forks, but the option to adjust whether node operators support the upgrade is a key feature of Ethereum’s governance.
For a more thorough overview of Ethereum’s governance process, see This lecture by Tim Baiko.
As an Ethereum MainNet user or an ETH holder, is there anything I need to do?
In short, no.
This announcement is only relevant to Ethereum testnets. More announcements will be made regarding Fusaka’s activation on Ethereum Mainnet, but even so, Ethereum MainNet users and ETH holders are not expected to have to take action.
As a non-staking testnet node operator, what should I do?
Update the node’s execution and consensus layer client to the versions listed in the table above to be compatible with any of these testnet upgrades.
As a testnet stander, what should I do?
Update the node’s execution and consensus layer client to the versions listed in the table above to be compatible with any of these testnet upgrades. Make sure both the beacon node and the validator client are updated.
As a node operator or a staker other than a testnet, what should I do?
There’s nothing for now. Further announcements will be made regarding Fusaka activation on Mainnet.
As an application or tool developer, what should I do?
Check the EIPs contained in Fusaka to determine whether and how the project will affect the project. Peerdas, SECP256R1 support, and the introduction of the new CLZ OpCode provide exciting opportunities for functionality and performance optimization.
Why “fusaka”?
Upgrading the running layer follows the name of the consensus layer following the Devcon City Names. “Fusaka” is a combination of Furu, the star of the Casiopeia constellation, and Osaka, the location of Devcon V.
