Fusaka testing has entered a critical phase, with Devnet 3 proving stable while Devnet 5 introduced new challenges around blob counts, bandwidth, & client performance. Developers have been addressing issues such as supernode misconfigurations, peer discovery delays, & cryptographic library flaws.
Ongoing analysis has helped refine feasible blob values, while security audits & syncing bug lists continue to guide progress. With testnet forks scheduled across Holesky, Sepolia, & Hoodi, Fusaka’s rollout is on track toward a carefully planned mainnet activation.
Fusaka Updates
Devnet 3 has proven to be very stable, maintaining over 96% validator participation with only minor issues reported. Teams have continued to push fixes into trunk branches that deploy automatically, keeping the network running smoothly without major attack simulations in the past week.
Devnet 5, however, introduced more complexity. It launched with 1,500 nodes and initially ran into issues when full nodes were mistakenly flagged as supernodes, causing 100% bandwidth utilization.
After resetting databases and clearing state values, stability improved, and blob performance tests were conducted at 15, 21, and 33 maximum blob counts. Analysis concluded that blob values of 15 and 21 were feasible for BPO 1 and 2, while 32 blobs created severe struggles for block propagation unless relays or high-bandwidth nodes were used.
Performance bottlenecks have also been observed, particularly in the Prysm client, which experienced excessive orphan blocks when running high blob counts with local block building enabled. Peer discovery delays further worsened block propagation, with builders forced to connect across 128 subnets and often requiring six to seven seconds for data broadcast.
Developers continue to track issues via the Fusaka syncing bugs list and review detailed testing analysis in the Devnet-5 BPO Analysis by PandaOps. The Fusaka testnet rollout follows a structured timeline.
The proposed schedule begins with a code freeze on 22 September 2025, allowing PandaOps to validate the frozen code as a release candidate. Shortly after, on 25 September, releases are planned for Holesky, Sepolia, and Hoodi testnets.
Forks would then follow in sequence:
- Holesky on 2 October (epoch 165376, 12:06:24 UTC)
- Sepolia on 16 October (epoch 273152, 14:12:48 UTC)
- Hoodi on 30 October (epoch 50944, 22:11:36 UTC)
- Mainnet would then activate Fusaka at the earliest 30 days after the Hoodi fork.
Barnabas has recommended that forks occur only on Wednesdays, which provide optimal debugging windows before and after the event, and also avoid conflicts with All Core Developers (ACD) calls. He further suggested that each BPO run sequentially before testnet forks, ensuring that sufficient analysis is completed at every stage before advancing to the next network.
One of the most significant issues uncovered during testing was within the c-kzg-4844 cryptographic library. Version 2.1.2 suffered from a flaw in how BLST handled points-at-infinity within its multi-scalar multiplication function.
This caused incorrect behavior at higher blob counts and was subsequently patched in v2.1.3, which is now the recommended version Developers can review the security audit in the zkSEC 2025 Audit Report.
Glamsterdam Updates
During ACDC #165, developers emphasized the importance of finalizing the scope of Glamsterdam by ensuring that all non-headliner EIPs are proposed before the Fusaka mainnet release. This approach helps maintain stability by preventing last-minute complexity and uncertainty in the upgrade process.
The planning for Glamsterdam involves careful sequencing of ePBS (Enshrined Proposer-Builder Separation) and BAL (Block Access Lists) testing. Developers debated whether both features should be merged into the same devnet or handled sequentially. The consensus leaned toward sequencing, as merging prematurely could complicate testing.
While merging both features once stable is desirable, the immediate recommendation is to progress linearly. Nimbus developers highlighted that implementing BALs on the Consensus Layer would require significant effort, making sequential testing more practical.
One proposal suggested initially running BAL-focused devnets exclusively with Prysm to avoid burdening all Consensus Layer (CL) clients. This would allow Prysm to test BALs independently, while other clients concentrate on ePBS.
This phased approach ensures work progresses on both tracks without overwhelming development teams. The technical dependency between BALs and ePBS was also discussed. Implementing Block Access Lists without ePBS would require state changes in the beacon chain, increasing maintenance complexity.
In contrast, with ePBS integrated, Block Access Lists become cleaner since no beacon state changes are required. The plan is therefore to use a temporary BAL-only branch to unblock near-term testing and transition to a BAL-on-ePBS model once minimal ePBS support is available.
The implications of this planning are significant for both client teams and governance processes. Splitting devnets between Prysm and other CL clients allows for a more balanced workload distribution, preventing bottlenecks and giving teams the flexibility to focus on their respective priorities.
Naming & Governance Updates
The discussion highlighted the need to finalize the naming of the upcoming upgrade following Glamsterdam. A community poll is running on Ethereum Magicians under the “H-Star” naming thread, where contributors can share suggestions & vote on the final choice.
The thread is available here: H-star name for consensus layer upgrade after Glamsterdam. Alongside the H-Star naming, developers also considered the replacement for the Sepolia testnet.
Another Magicians thread requests community input for this new name: Testnet name needed for Sepolia replacement. While long-term support notes had indicated Sepolia’s sunset, several maintainers argued that it should not be retired too abruptly.
To reduce migration pressure, a grace period will be introduced, during which Sepolia & its replacement will run in parallel. Governance discussions also touched on whether to coordinate a single combined release for all testnets or stagger releases individually.
A single release offers simplicity but carries the risk that if one testnet fails, all subsequent steps face emergency delays. Client developers further emphasized the need to update the Ethereum eth-clients repository promptly, since Nimbus and others depend on it as the source of truth for Holesky, Sepolia & Hoodi fork parameters.
Miscellaneous Updates
The Ethereum Foundation has launched a $2 million audit contest for Fusaka, designed to uncover last-minute bugs and security vulnerabilities before mainnet release. The official announcement is available on the Ethereum Blog.
During ACDC-165, contributors stressed the importance of active client participation in reviewing submissions, giving severity feedback, and preventing duplicate reports from lingering unaddressed. For ongoing tracking, the Fusaka syncing bugs board was shared as a reference to help teams and auditors monitor issues.
A specific pull request on Prysm’s implementation of BAL features is also active: OffchainLabs/prysm #15712. Additionally, a Discord thread was linked for discussions on gas and transaction limits, ensuring cross-client alignment.
Backfill implementation updates were another focus point. Lighthouse confirmed that its backfill is already functional, while Prysm is still testing its own version.
Grandine reported that backfill integration will be merged soon. This feature remains crucial for validator synchronization during blob-heavy workloads.
The agreed timeline sets September 22nd, 2025 as the code-freeze date, followed by PandaOps validation runs, with releases scheduled for September 25th. Testnet forks are then staged across October: Holesky on the 2nd, Sepolia on the 16th, and Hoodi on the 30th.
Mainnet would be targeted no earlier than thirty days after Hoodi’s fork. Developers joked about “Merge Day” celebrations, shared emoji reactions, and expressed excitement at finally aligning schedules to slot boundaries.
If you find any issues in this blog or notice any missing information, please feel free to reach out at yash@etherworld.co for clarifications or updates.
Related Articles
