What is Fusaka?
On Dec. 3, 2025, Ethereum will activate the Fusaka upgrade on mainnet, its second major hard fork of the year after Pectra in May.
Rollups now carry the bulk of Ethereum transactions and fee revenue, yet they are still constrained by how much data they can post back to the layer 1 and what it costs.
Fusaka is designed to relieve that pressure. Its headline feature, PeerDAS (peer data availability sampling), lets validators verify rollup blob data without downloading everything, cutting bandwidth and storage requirements while opening the door to much higher data throughput.
At the same time, blob-only parameter (BPO) forks, new gas and block-size limits and history expiry tweaks prepare the chain for repeated capacity increases instead of one-off jumps.
In this article, we will unpack what Fusaka changes, where it sits in the Surge, Verge and Purge roadmap, and what it could mean for users, rollups and the broader Ethereum ecosystem over the next few years.
Fusaka’s name comes from two internal upgrade code names, Osaka (Execution Layer) and Fulu (Consensus Layer), merged into “Fusaka.”
From Merge to Fusaka: The Roadmap
To see where Fusaka fits, it helps to zoom out.
- •The Merge (2022) shifted Ethereum from proof-of-work to proof-of-stake, cutting energy use by around 99.9%.
- •Shapella (2023) enabled staked Ether (ETH) withdrawals, turning a one-way staking system into a liquid one and attracting more validators.
- •Dencun (March 2024) introduced Ethereum Improvement Proposal (EIP) 4844 “blobs,” a cheaper, temporary data lane for rollups, also known as protodanksharding.
- •Pectra (May 2025) added EIP-7702 account abstraction features and revamped staking parameters like the 2,048-ETH validator cap.
Those upgrades lined up with Vitalik Buterin’s shorthand roadmap: Merge, Surge, Verge, Purge and Splurge. The Surge is about scaling Ethereum through rollups and better data availability, while the Verge and Purge focus on lighter clients and pruning old history.
Fusaka is the first upgrade that pushes on all of those levers at once. It scales data for rollups as part of the Surge and leans into history expiry and lighter sync as part of the Verge and Purge. It also sets a clear target for a modular Ethereum stack aiming for more than 100,000 transactions per second (TPS) when you add up layer-2 throughput on top of L1 settlement.
PeerDAS, Blobs, and Bigger Blocks
Fusaka’s core scaling change is EIP-7594, PeerDAS.
Instead of every full node downloading entire blobs of rollup data, PeerDAS splits them into smaller cells and uses sampling and erasure coding so validators fetch only random pieces. If enough pieces are available, the network can be confident that the full data exists.
That reduces per-node bandwidth and storage and sets the stage for an eventual 8x increase in blob capacity over time without forcing home stakers onto data center hardware.
To make that growth more flexible, EIP-7892 introduces Blob Parameter Only (BPO) forks, tiny hard forks that change only three blob-related parameters: target, max, and the base fee adjustment factor.
After Fusaka, Ethereum can raise blob capacity in smaller and more frequent steps as L2 demand grows rather than waiting years for a big bang fork.
On the execution side, Fusaka updates gas and block sizing:
- •The effective block gas target is raised from today’s 45 million toward much higher ceilings. EIP-7825 caps the gas a single transaction can use, and EIP-7934 adds a 10 MB Recursive Length Prefix block size limit to reduce denial-of-service risk.
- •EIP-7823 and EIP-7883 reprice and limit the MODEXP precompile so that one heavy cryptographic call cannot stall an entire block.
In plainer language, Fusaka gives Ethereum more room for rollup data and complex transactions while adding guardrails so blocks stay verifiable for regular nodes.
Blobs are temporary data packets posted by rollups to Ethereum. They are cheaper than call data and are automatically pruned after about 18 days, so they do not bloat the chain.
UX, Security, and Dev Tools
Not everything in Fusaka is about raw capacity. Several EIPs focus on user experience, security, and developer ergonomics.
EIP-7917 (deterministic proposer lookahead) makes the proposer schedule for the next epoch fully deterministic and accessible onchain through the beacon root. This matters for based rollups and pre-confirmation schemes that need to know in advance which validator will propose a given block to offer fast and credible soft finality guarantees.
On the user experience (UX) side, EIP-7951 adds a secp256r1 precompile, giving Ethereum native support for P-256 signatures, the curve used by Apple’s Secure Enclave, Android Keystore, Fast Identity Online 2 (FIDO2), and WebAuthn passkeys. This lets wallets rely on device-level biometrics and passkeys rather than seed phrases, bringing layer 1 closer to mainstream fintech login flows.
Developers get EIP-7939, the count leading zeros opcode, which counts leading zeros in a 256-bit word. It makes bit-level math, big integer arithmetic, and some zero-knowledge proof circuits cheaper and easier to implement.
Finally, EIP-7642 extends Ethereum’s history expiry work, allowing clients to drop more pre-Merge and older data while advertising which ranges they serve. This can save hundreds of gigabytes per node and can meaningfully speed up sync for new validators.
Who Gains What: L2s, Validators, and ETH Holders
For L2 ecosystems, the story is straightforward. PeerDAS and BPO forks combine to make data cheaper and more abundant.
Analysts estimate that Fusaka plus the first BPO fork could cut L2 data fees by 40%-60% over time, especially for high-throughput use cases like DeFi, gaming, and social. Cheaper blobs mean more room for experimentation and potentially a fresh round of competition between rollups on price and user experience.
For node operators and validators, Fusaka lightens some loads and adds others. Sampling and history expiry reduce how much data nodes need to download and store, making it much easier for new nodes to sync to the latest block.
However, as BPO forks dial blob counts higher, well-provisioned validators and infrastructure providers will shoulder more upload bandwidth, which could subtly nudge the network toward larger operators if client implementations and guidance are not careful.
Institutions and staking providers tend to frame Fusaka as a strategic enabler rather than a one-off speed boost. More predictable data throughput, safer gas and block size limits, and cleaner history management all make large-scale validator operations easier to plan.
For ETH holders, the impact is straightforward. Ethereum’s base layer is being tuned as a high-capacity settlement and data engine for L2s, with minimum fees and blob pricing adjusted so more activity settles on Ethereum, which can influence fee markets and validator rewards depending on demand.
There are trade-offs, though. The protocol becomes more complex, and a stronger focus on monetization could draw criticism if everyday users do not feel clear improvements in cost and experience.
During the final coordination call for Fusaka, the activation slot was set at slot 13,164,544, expected around 21:49 UTC on Dec. 3, for mainnet.
After Fusaka: Glamsterdam and the Road to 100,000 TPS
The next named upgrade, Glamsterdam, is expected to land in 2026 and already has two headliners: enshrined proposer builder separation (ePBS) and block-level access lists (BALs).
- •ePBS aims to harden the maximal extractable value (MEV) supply chain by splitting block building and proposing at the protocol level rather than relying only on external relays.
- •BALs target more efficient execution and better handling of state access, including future increases in blob capacity.
PeerDAS and BPO forks move the Surge forward. History expiry extensions and peer-to-peer (P2P) tweaks carry the Verge and Purge themes. User experience upgrades like proposer lookahead and P-256 support make pre-confirmations and passkey wallets realistic at scale.
If Ethereum delivers on this cadence, Fusaka will be remembered less as a single event and more as a turning point. It marks the moment when the roadmap shifted into a coherent and value-aware scaling program. It aims to support a 100,000 TPS modular stack without abandoning the decentralization that made the network valuable in the first place.