Figuring out Fusaka
Why I don't think Fusaka ships in 2025
Good evening,
Today’s post is all about the Fusaka upgrade. In lieu of my usual coverage on the latest Ethereum developer call, I prepared a write-up inspired by a presentation I gave at ETHSeoul 2025 this week about what code changes are being considered for the next hard fork after Pectra. It also features insights into the Fusaka implementation process and timeline.
I hope you find the information and insights below on Fusaka useful. Stay tuned for my belated ACD Call Minutes and Insights on the latest ACD call, ACDC #155, coming out later this weekend!
Yours Truly,
Christine D. Kim
Fusaka EIPs
So far, only two EIPs are officially included in Fusaka: PeerDAS and EOF.
PeerDAS is the most important code change developers unanimously want to prioritize in Fusaka. It is the headliner feature that client teams say should exclusively dictate the timeline for Fusaka. All other EIPs included in Fusaka, including EOF, will be considered secondary to PeerDAS and left out of Fusaka if it appears that these EIPs are slowing down the timeline for shipping PeerDAS.
PeerDAS stands for Peer Data Availability Sampling. It is a new networking protocol that will allow consensus layer (CL) nodes to sample data from blob transactions to verify that the entire blob data set was posted on-chain. As background, blobs, a.k.a. binary large objects, are a cost-effective way to post large amounts of data to Ethereum. They were introduced through the Dencun upgrade as a new transaction type with its own separate fee market and block space. (For more information about blobs, read this report I wrote for Galaxy.)
PeerDAS is expected to scale Ethereum’s blob capacity without increasing CL node bandwidth and hardware requirements. Through PeerDAS, CL nodes can download a fraction of a blob, instead of the full blob, to process and validate this data on-chain. Currently, developers are testing PeerDAS with a target blob count of 12 blobs per slot, which is double the blob capacity of Ethereum once Pectra goes live on the network. However, in theory, developers anticipate being able to increase Ethereum’s blob capacity by up to a target of 50 blobs per block with PeerDAS.
The second and only other EIP that developers have officially started to work on for the Fusaka upgrade is EOF. EOF stands for Ethereum Virtual Machine Object Format. EOF is a bundle of 12 EIPs that modifies the structure and logic of Ethereum’s execution environment, the EVM. It represents the first significant upgrade to the EVM that aims to make smart contract code execution safer, more predictable, and more efficient.
If EOF is ready for implementation before PeerDAS, developers may expand EOF to encompass four additional EIPs. Technically, according to the terminology of ACD calls, PeerDAS and EOF are “scheduled for inclusion” (SFI’d). The four EOF EIPs that may be implemented later in Fusaka are “considered for inclusion” (CFI’d).
Aside from the EOF-related CFI’d EIPs, there is a list of nine other CFI’d EIPs for Fusaka. Below is a high-level summary of the full SFI’d and CFI’d EIP list for Fusaka as of April 16, 2025:
Fusaka Process
The list of Fusaka EIPs may get longer. Developers finalized the CFI list for EL-focused EIPs in Fusaka on ACDE #209, but they have yet to finalize the CFI list for CL-focused EIPs. They intend to do that on the next ACD call, ACDC #155, which I will have a write-up on coming out tomorrow!
Once the two CFI lists are finalized, the process for implementing and testing the Fusaka upgrade is expected to flow as follows:
Test SFI’d EIPs separately. This is how developers are presently testing PeerDAS and EOF. They are testing these EIPs on separate developer-focused testnets, also called devnets.
Fusaka Devnet 0. Once PeerDAS and EOF implementations are stable, developers will merge these testing efforts and start testing SFI’d EIPs on the same devnet.
Reopen Fusaka scoping discussions. As developers gain confidence in their implementations of Fusaka SFI’d EIPs, they will open up discussions on what EIPs from the CFI’d lists they should start adding to the upgrade.
Test newly SFI’d EIPs on Fusaka devnets.
Prepare client releases for public testnet upgrades.
Public testnet upgrades.
Ethereum mainnet upgrade.
Developers have a long way to go before Fusaka is ready for Ethereum mainnet. The upgrade implementation and testing process is just beginning, which is why I don’t think it is realistic for developers to ship Fusaka by the end of the year.
The last three milestones in the process above will take developers at least two and a half to three months to complete, according to the new Ethereum Protocol Upgrade Process, but most likely longer, especially if the public testnet upgrades for Fusaka go as poorly as the way the public testnet upgrades for Pectra went.
Though it is difficult to estimate any timeline for Fusaka this early into upgrade scoping and implementation efforts, I estimate the upgrade will go live on mainnet sometime next year in 2026.
If you’d like to dig deeper on the state of Fusaka planning, here are some additional resources:
Fusaka Meta EIP: This is the official document that lists the EIPs that have been scheduled, considered, proposed, and declined for inclusion in Fusaka.
PeerDAS Devnet 6 Specifications: The latest devnet developers have launched to test PeerDAS.
EOF Devnet 0 Specifications: The latest devnet developers have launched to test EOF.
Ethereum Protocol Upgrade Process: Created by Ethereum Foundation Researcher Fredrik Svantes, this document formalizes the necessary milestones client teams should reach and timelines to adhere to before activating an upgrade on Ethereum.
Thank you for subscribing to ACD After Hours! If you like what you read, consider sharing it with a friend who might also enjoy the content.
I would greatly appreciate feedback on the ACD After Hours newsletter. If today’s post sparked any thoughts, opinions, or questions, please share your feedback by responding to the poll below or leaving a comment. Thank you!
Special thanks to Shinhye Kim for the graphics in this newsletter.