Ethereum’s next hard fork, colloquially dubbed Fusaka, is slated for around November 2025. It won’t rearrange anyone’s wallet UI or force token migrations; it’s an engineering tune-up that bundles roughly a dozen protocol changes aimed at making the network lighter, tougher, and easier to build on. Think server-room overhaul, not new app icon. The work targets data availability for rollups, smarter resource limits, and a handful of EVM and cryptography tweaks that remove recurring pain points for client teams and developers. Media briefings and community trackers point to an 11-EIP package with a November window, consistent with the cadence after Pectra in May and Dencun in early 2024.
Why the unflashy approach is a feature, not a bug
Post-Merge Ethereum has settled into a rhythm: ship foundational throughput and reliability improvements at Layer 1 so that most user-visible wins happen on Layer 2. Dencun’s EIP-4844 (“blobs”) made L2 data far cheaper, which is why rollup fees collapsed in 2024; Fusaka keeps turning that flywheel by improving how the network moves and verifies data rather than adding glitzy features. It’s the difference between a faster motorway and nicer paint on the car.
The headline mechanics: PeerDAS, blobs, and bounded resources
A good chunk of Fusaka’s value traces to EIP-7594 (PeerDAS), which lets beacon-chain nodes sample pieces of blob data instead of pulling the whole payload every time. With enough independent samplers, the network gets high assurance that the full data exists while dramatically cutting per-node bandwidth and storage needs. That’s exactly the pressure valve rollups want as they scale throughput without dumping heavyweight requirements on every validator.
Dencun’s blob design was deliberately forward-compatible with data-availability sampling, and core developers have been explicit about using parameterized “blob-only” changes to scale supply when needed. EIP-7892 formalizes that idea: lightweight Blob Parameter Only hard forks that adjust blob targets and caps without dragging the rest of the protocol along. It’s plumbing, but it’s the kind that keeps L2s breathing room as demand fluctuates.
On the execution side, Ethereum continues a years-long campaign to bound worst-case work so a single transaction can’t hold blocks hostage. EIP-7825 proposes a per-transaction gas ceiling (initially framed at 30M gas) to nail down execution time; discussion has since turned to an even tighter 16.7M cap (EIP-7983) to better match real-world usage and avoid pathological deployments. In parallel, EIP-7823 and EIP-7883 clamp inputs and raise costs for the notoriously tricky MODEXP precompile, whose under-pricing has been a magnet for DoS-style edge cases. The theme is simple: keep L1 predictable as volumes rise.
Under-the-hood quality-of-life for builders
Fusaka is also where several developer-facing proposals finally graduate. EIP-7939 adds a CLZ (“count leading zeros”) opcode—unsexy to civilians, but a boon for bit-level math in cryptography and compression. EIP-7951 introduces a secp256r1 (P-256) precompile, aligning Ethereum with the cryptography widely used in WebAuthn, iOS, and enterprise HSMs—an integration accelerator for mainstream wallet flows. And EIP-7907—which meters contract size and raises the long-standing 24 KB ceiling—has been debated as a way to reduce contortions in complex deployments, though client teams have weighed whether it lands in Fusaka or is staged for a later fork.
Light clients, Verkle, and the “run-a-node-on-a-laptop” dream
A persistent storyline since the Merge is making real verification possible on phones and modest hardware. Verkle trees—a commitment scheme that slashes proof sizes—are the marquee step on that path. Whether Fusaka ships the full Verkle transition or primarily lays groundwork, the direction is clear: slimmer witnesses, faster sync, and fewer excuses not to verify your own state. Ethereum’s own roadmap documentation frames Verkle as the key to light-client-first Ethereum.
What regular users may notice (eventually)
No dramatic day-one experience shift is expected. If Fusaka lands as designed, L2 fees should keep trending down and capacity up, especially as blob parameters are nudged via BPO hard forks; wallets and mobile clients get incrementally more trust-minimized as light-client tooling improves; and throughput debates will continue as clients calibrate block gas defaults (there’s even an EIP to encourage higher defaults over time, independent of governance polling). These are structural—not overnight—improvements.
The part Ethereum doesn’t mind you forgetting: upgrades have broken things before
Ethereum’s conservative pacing is learned behavior. In 2016, a series of DoS attacks forced back-to-back emergency hard forks—Tangerine Whistle and Spurious Dragon—to reprice opcodes and “de-bloat” state. It worked, but it also underlined how brittle unbounded resources can be.
In April 2021, the Berlin hard fork exposed a bug in the OpenEthereum client that briefly knocked nodes out of sync, prompting exchanges to pause withdrawals while a fix shipped. Four months later, parts of mainnet split when some operators failed to upgrade Geth to a patched release; those running the old software followed the wrong chain until coordination recovered. These weren’t catastrophic, but they are cautionary tales about client diversity and upgrade discipline.
Even post-Merge, the Beacon Chain suffered loss-of-finality incidents in May 2023 due to load-related bugs in popular consensus clients. Blocks kept coming and patches arrived quickly, but finality stalled for tens of minutes—an uncomfortable reminder that scaling stresses don’t always show up where you expect. Fusaka’s resource-bounding EIPs are designed, in part, to keep these failure modes rare and contained.
How Fusaka fits the 2025 arc
The year opened with Pectra (May 7, 2025), a dual-layer upgrade that among other things raised validators’ max effective balance to 2,048 ETH, simplified staking operations, and introduced UX-oriented changes on the execution layer. That was the “human-facing” cleanup after the Merge era. Fusaka is the industrial follow-through: pushing data systems toward sampling, guarding hot paths with strict caps, and broadening the EVM’s native toolkit to match what modern apps want to do.
The politics of headroom
Expect debate to keep simmering over block gas limits. One track, EIP-7935, encourages clients to ship higher default limits over time (some operators have already nudged mainnet higher); another line of research explores more aggressive schedules. At the same time, the per-transaction cap proposals (EIP-7825/EIP-7983) pull the other way—tightening single-tx risk even as total block capacity grows. That yin-yang—more throughput, fewer foot-guns—is the philosophical center of Fusaka.
What’s at stake
If Fusaka ships cleanly, L2s get steadier, cheaper bandwidth; client teams can defend against known attack surfaces without guesswork; and developers shed some of the baroque workarounds that have accreted since 2016. If it stumbles, history suggests the trip-wires: coordination lapses that leave pockets of the network on the wrong software, client monocultures that turn a single bug into a network event, or parameter shifts that ripple in unexpected ways through rollup sequencers and provers. The playbook—heavy testnets, conservative defaults, staged feature gates—reflects scars from past incidents and is precisely why these infrastructure-first forks matter.
Read about how Ethereum network upgrades can impact Layer 2 scaling solutions.
