Ethereum “Fusaka” Upgrade
The Ethereum "Fusaka" upgrade, set for mainnet launch in early December 2025 after successful testnet deployments, is a significant advancement incorporating 13 Ethereum Improvement Proposals (EIPs). These EIPs focus on crucial areas like scaling, performance, and enhancing both user and developer experience, laying the groundwork for future Ethereum developments.
TL;DR
The Ethereum "Fusaka" upgrade is set to launch on the mainnet in early December 2025, following successful testnet deployments in October. This upgrade incorporates 13 Ethereum Improvement Proposals (EIPs) focused on scaling, performance, and user/developer experience.
Last Upgrade: Pectra
On our last update on Ethereum Upgrades, we studied "Ethereum Pectra Upgrade" and its most important impacts. Some of the most important proposals in that upgrade EIP-7691 with enhanced scalability for L2s, EIP-7251 with raising stake cap to enhance security, EIP-2537 with reduced gas cost for cryptographic tasks, improving developer efficiency, and EIP-7702 with programmable EOAs, enhancing user experience.
Maybe the most important EIP in terms of short term effect in Pectra upgrade is EIP-7702 that enables developers to program EOAs and do transactions and calculations that were only available to smart contracts. Some notable activities are "batch transactions," where you can send multiple transaction (e.g., token approval and token transfer) in one transaction, and "gas sponsorship", where you can hold no gas token ($ETH) and someone else pays the gas of the transaction for you in the native token.
Almost 7 months after this impactful upgrade, and Ethereum is all ready for the next big upgrade: "Fusaka".
Deployment Timeline and Testnet Performance
Ethereum’s Fusaka network upgrade is on track to go live on mainnet by early December 2025, following a series of successful testnet activations. The upgrade was deployed on three public test networks in October 2025: Holešky (activated Oct 1, 2025), Sepolia (Oct 14, 2025), and Hoodi (Oct 28, 2025). All three testnets forked as planned with high participation and stable multi-client performance, clearing the way to schedule the mainnet fork approximately 30+ days after the final Hoodi test. (Notably, Fusaka will be the last upgrade run on Holešky, which is being deprecated and shut down after fulfilling its testing role.)
Public testnets successfully addressed critical issues before the mainnet release, with only minor adjustments emerging. A key change, introduced by Fusaka’s PeerDAS feature, altered blob transaction proofs from “blob proofs” to “cell proofs.” This surprised some Layer-2 rollups, requiring recomputation of proofs for already-signed transactions. Ethereum developers quickly communicated this, urging L2 sequencers to update their code. This successful testnet discovery allowed issues to be resolved well before Fusaka's mainnet launch. With all rehearsals complete and only minor tweaks needed, developers are now finalizing the mainnet activation slot.
EIPs Included in the Fusaka Upgrade
Fusaka incorporates a bundle of 13 EIPs covering major scaling features, performance optimizations, and user/developer improvements. Below is a breakdown of the included EIPs and their purposes:
Data Availability & Blob Scaling
Proposed by Danny Ryan and Dankrad Feist, PeerDAS is a new gossip-based protocol enabling Ethereum nodes to verify blob data availability by sampling small pieces instead of downloading full blobs. This key advancement uses erasure-coded "cells" and KZG commitments for cryptographic assurance that blob data is available network-wide, while only fetching random portions. PeerDAS increases blob throughput without sacrificing security or decentralization, directly benefiting Layer-2 rollups with higher capacity, lower costs, and strong data availability on L1. EIP-7594 limits each blob-carrying transaction to a maximum of 6 blobs to prevent overloading block producers.
Proposed by Mark Mackey and Raúl Kripalani, BPO forks offer a lightweight method to incrementally scale blob capacity through mini-upgrades that adjust only blob-related parameters. This allows for quick adjustments to blob throughput in response to demand, bypassing large hard forks and minimizing coordination overhead. Fusaka will initiate this with two post-Fusaka BPO forks on testnets (and eventually mainnet): BPO1 will increase blobs per block from 6/9 to 10/15, and BPO2 will further raise it to 14/21. This stepwise ramp-up, after PeerDAS activation, enables developers to monitor network performance and safely increase data availability for rollups.
Proposed by Anders Elowsson et al., improves the economics of blob fee auctions to ensure blob consumers pay a fair share of network resources. In today’s design, if execution gas fees dominate total transaction cost, the blob base fee mechanism can get “stuck” near zero (as blob usage appears under target). EIP-7918 fixes this by imposing a reserve price: it introduces a rule that the cost of blob gas cannot drop below the cost of a certain amount of execution gas (defined by a constant BLOB_BASE_COST). In simple terms, if execution is congested (high base fee per gas), the protocol will not keep lowering blob fees to meaningless levels. Instead, blob base fee stays elevated until it meaningfully reflects the compute load those blobs impose. This change ensures the blob fee market remains functional, preventing blobs from effectively becoming “free” when execution is expensive, and that rollups pay at least a baseline cost for the computation (KZG proof verification, etc.) that they require nodes to perform. Overall, this EIP makes blob pricing more stable and responsive to real network conditions, avoiding pathological cases of 1-wei blob fees.
Execution Layer Performance & Gas Changes
Giulio Rebuffo and Toni Wahrstätter proposed a 2^24 gas (≈16.8M) per-transaction cap, effective in Fusaka. This prevents single transactions from consuming an entire block's gas (previously 30-45M), addressing denial-of-service risks and enabling future parallel execution. This cap ensures multiple transactions per block, improving packing and predictability. Most users won't be affected, but large operations or deployments nearing the old block gas limit must now split calls. Fusaka's testnets (Sepolia, Holešky) already enforce this cap, allowing developers to adapt.
Sophia Gold et al. propose increasing the target gas limit per block to 60 million for the Fusaka era, doubling L1 execution throughput. This EIP updates client software defaults, signaling validators to adopt the 60M gas target, which has been extensively tested for network stability and client performance. This is a default configuration update, not a consensus rule, but it encourages validators to increase the limit from the previous 30M-45M levels.
EIP-7934 proposes a 10 MiB RLP-encoded size cap for execution payloads (blocks), effectively setting an 8 MiB limit for the execution payload itself, with 2 MiB reserved for beacon chain data. This prevents overly large blocks that could strain network propagation or exceed the consensus layer's gossip limits (around 10MB). The cap ensures network stability even if gas limits increase, addressing issues like bloated calldata or logs not fully constrained by gas alone.
EIP-7883 and EIP-7823 enhance the predictability and security of the ModExp precompile. EIP-7883 increases ModExp's minimum gas cost from 200 to 500, triples the general gas cost formula, and adds a cost multiplier for large exponents. This prevents underpricing in worst-case scenarios, especially with higher block gas limits. EIP-7823 sets an 8192-bit (1024-byte) upper bound for each ModExp input (base, exponent, and modulus). This mitigates edge-case consensus bugs and impractical execution times, as 8192 bits cover all real-world uses and no legitimate calls have exceeded this size. Together, these EIPs align ModExp's gas cost with its computational cost, restrict pathological inputs, and improve network stability, allowing for safer increases in block gas limits.
EIP-7642 proposes eth/69, a new Ethereum peer-to-peer protocol. It removes legacy "total difficulty" and receipt bloom filters, saving 530 GB bandwidth during full sync. It also adds history serving window announcements, helping nodes find partners with older blocks after the May 2025 history pruning. This streamlines the protocol for a post-Merge, history-pruned Ethereum, boosting efficiency and robustness.
User & Developer Experience Improvements
Carl Beekhuizen and others propose a new precompiled contract at 0x100 for ECDSA signature verification on the secp256r1 curve (P-256). This curve is used by many secure hardware devices (e.g., Apple Secure Enclave, YubiKeys, FIDO2/WebAuthn). Previously, Ethereum lacked native P-256 support, making on-chain verification expensive or impossible. This precompile enables efficient verification of signatures from hardware wallets, smartphones, and biometric devices, reducing friction for mainstream adoption by supporting familiar login flows. The EIP-7951 implementation includes proper validation, fixes a security issue, and costs ~6900 gas per verification. This empowers developers to integrate "login with FaceID/TouchID" or enterprise HSM signatures directly into Ethereum applications, enhancing security and user experience.
Vectorized et al. propose a new EVM opcode, CLZ, to count leading zero-bits in a 256-bit word. This low-level operation is crucial for efficient big integer arithmetic, bit-level math, data compression, and some cryptographic schemes. Previously, CLZ required costly workarounds. The new opcode offers a native, gas-efficient instruction, simplifying smart contract code and reducing gas consumption, especially for zero-knowledge proofs. This enhances the EVM's instruction set, making advanced math and cryptography more affordable on-chain.
EIP-7910 introduces a new eth_config RPC endpoint, allowing node operators to query their node's chain configuration and upcoming fork schedule. This helps detect misconfigurations before a fork occurs, preventing nodes from falling out of consensus. It provides a structured report of network parameters, including fork activation times and Blob-specific settings. This "quality-of-life improvement for DevOps" makes Ethereum upgrades more transparent and reduces the risk of chain splits due to configuration errors.
Consensus Layer Refinement
EIP-7917, proposed by Lin Oshitani and Justin Drake, makes the beacon chain's proposer schedule fully deterministic one epoch in advance. Previously, validator effective balances could change, causing slight unpredictability and opening doors to "grinding" strategies. EIP-7917 resolves this by pre-computing and storing the proposer list for the next epoch, fixing assignments for MIN_SEED_LOOKAHEAD+1 epochs. This benefits "based pre-confirmation" protocols and PBS (Proposer-Builder Separation) by providing a stable, known-in-advance schedule, preventing manipulation, and simplifying security analysis. In essence, EIP-7917 tightens consensus rules for a predictable and manipulation-resistant block proposer rotation, enabling more robust block building designs.
What Affects Who
Ethereum has many moving parts with different stakeholders; Users who sign and pay for transactions; dApp Developers who write and deploy smart contracts; Validators who build and attest to blocks; RPC Nodes / Infra providers who run full nodes, gateways, and tooling; and Rollups / L2s that post data to L1 and inherit its security. Below maps Fusaka’s EIPs to those groups and explains the practical impact.
Beyond Fusaka: A Glimpse at “Glamsterdam”
Ethereum developers are planning "Glamsterdam," the next major upgrade, following Fusaka. Named after Amsterdam and a star (likely "Glamis"), Glamsterdam will focus on enshrined Proposer-Builder Separation (ePBS) and Block-level Access Lists (BAL).
Developers are prototyping and testing ideas for Fusaka, while smaller Glamsterdam EIPs are under consideration. Glamsterdam is targeted for mid-to-late 2026.
Conclusion
With the "Fusaka" upgrade successfully tested and slated for early December 2025, Ethereum is poised for significant advancements in scaling, performance, and user experience. This upgrade, incorporating 13 key EIPs, sets the stage for future developments like "Glamsterdam" in 2026, which will focus on enshrined PBS and Block-level Access Lists, ensuring a more robust and efficient Ethereum ecosystem.
Resources
Frequently asked questions
Check out most commonly asked questions, addressed based on community needs. Can't find what you are looking for?
Contact us, our friendly support helps!
How will Fusaka affect Layer-2 fees and throughput?
PeerDAS plus staged blob increases (via BPO forks) expand blob capacity, improving data availability for rollups, typically lowering L2 fees and boosting throughput when demand rises.
Do dApp developers need to change contracts for Fusaka?
Most apps won’t. Watch for gas-sensitive code (ModExp repricing), very large batch calls (now capped per-tx), and consider using the new secp256r1 precompile and CLZ opcode where relevant.
What should node operators/validators do before the fork?
Upgrade clients for eth/69, enable PeerDAS, verify fork settings via the new eth_config RPC, and ensure hardware/network can handle larger default block gas (60M) and the new payload size cap.
