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.
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
This section maps each Fusaka EIP to the main stakeholder groups in Ethereum. If an EIP has no meaningful direct impact on that group, it’s marked ❌. If it does, we explain briefly how.
| EIP | Users | Core Developers | dApp Developers | Validators | RPC Nodes / Infra | Rollups / L2s |
|---|---|---|---|---|---|---|
| EIP-7594 (PeerDAS) | Lower L2 fees over time as data availability scales. | Must implement PeerDAS logic (sampling, cell proofs) in clients and ensure network safety. | ❌ | Must participate in PeerDAS data availability sampling in block production/validation. | Nodes need to gossip and serve sampled cells instead of full blob data. | Critical: enables higher blob throughput using data availability sampling instead of full downloads. |
| EIP-7892 (Blob Parameter Only forks) | Indirect fee relief on L2s as blobs per block are raised in controlled steps. | Must coordinate and ship BPO fork configs that only touch blob parameters. | ❌ | May need to update configs for new blob target/max at each BPO fork. | Need to track evolving blob parameters post-Fusaka. | Direct benefit: staged blob cap increases (6→10→14 target blobs) increase data bandwidth for rollups. |
| EIP-7918 (Blob Base Fee bounded by execution cost) | More predictable L2 fees; prevents “almost free blobs” that could later spike. | Must update blob fee logic so blob base fee respects execution load. | ❌ | Enforces new fee accounting rules when proposing/validating blob-bearing blocks. | Nodes must apply new blob base fee calculation to remain in sync. | Ensures rollups pay a fair baseline for blob data even when execution gas is high. |
| EIP-7825 (Per-transaction gas cap ~16.8M gas) | ❌ (normal wallets rarely hit this cap). | Sets new consensus rule; requires auditing edge cases like giant batched txs. | Must split extremely large deployments / batch ops into multiple txs. | Must reject and not build txs above the per-tx gas ceiling. | ❌ | ❌ |
| EIP-7935 (Block gas target ~60M) | Cheaper / faster mainnet txs due to higher throughput capacity. | Need to tune clients for performance and memory at 60M gas blocks. | Benefit: more headroom per block for complex contracts and high activity periods. | Validators gradually vote block gas limit upward via client defaults; higher load per block to process. | Infra must handle heavier blocks (bandwidth, CPU) at new default target. | ❌ |
| EIP-7934 (10 MiB execution payload size cap) | ❌ | Add explicit RLP-encoded block size checks to execution clients. | Slight constraint on extreme calldata patterns; forces more efficient calldata usage. | Must not produce oversized (~10 MiB RLP) payloads; blocks violating the cap are invalid. | Nodes reject / gossip-filter blocks exceeding the byte-size limit, improving network stability. | ❌ |
| EIP-7883 (ModExp gas repricing) | ❌ (felt only in very exotic cryptography-heavy txs). | Update ModExp precompile pricing math to remove underpriced worst cases. | Contracts doing large RSA / big-int math will pay more gas; encourages efficiency. | Lowers DoS risk from underpriced ModExp during block building. | ❌ | ❌ |
| EIP-7823 (ModExp 8192-bit input cap) | ❌ | Enforce hard upper bound on ModExp input sizes to avoid pathological cases. | Smart contracts relying on absurdly huge (>8192-bit) RSA-style ops must refactor. | Reduces risk that one huge ModExp call stalls block execution. | ❌ | ❌ |
| EIP-7642 (eth/69 network protocol) | ❌ | Must ship eth/69: removes obsolete PoW-era fields, adds history serving window, drops receipt blooms. | ❌ | Bandwidth savings and more predictable sync because peers advertise what history they can serve. | Huge impact: less wasted bandwidth (no receipt bloom spam), cleaner handshake, better partial-history sync. | ❌ |
| EIP-7951 (secp256r1 precompile) | Enables “Sign with FaceID / phone secure element / WebAuthn” style wallets natively and cheaply. | Add and audit new P-256 verification precompile in clients. | Lets devs verify P-256 signatures on-chain at low gas, enabling passkey-style wallets and enterprise auth flows. | ❌ | ❌ | ❌ |
| EIP-7939 (CLZ opcode) | ❌ | Add new EVM opcode and define its gas semantics. | Gives a cheap primitive for bit math / big-int / ZK helper logic, lowering gas for advanced crypto/math-heavy contracts. | ❌ | ❌ | ❌ |
| EIP-7910 (eth_config RPC) | ❌ | Lets core/devops compare upcoming fork parameters programmatically across clients to catch misconfig before forks. | ❌ | Validators / staking ops can automatically verify they’re on the right fork settings ahead of upgrades. | Big win for infra: RPC exposes chain config, fork schedule, blob params so ops can audit fleet consistency. | ❌ |
| EIP-7917 (Deterministic proposer lookahead) | ❌ | Requires consensus-layer changes to precompute proposer sets one epoch earlier and store them. | ❌ | Validators get a fixed, manipulation-resistant proposer schedule for the next epoch, enabling better PBS / MEV coordination and removing last-minute balance “grinding.” | ❌ | ❌ |
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.
