What Is the Ethereum Fusaka Upgrade? Dev Guide to 12 EIPs

The Fusaka upgrade is Ethereum’s next major hard fork, tentatively targeting mainnet activation on December 3, 2025. It’s already live on testnet for early integration and developer testing.

Fusaka picks up where Pectra left off, introducing 12 protocol changes (EIPs) that deepen Ethereum’s scalability, validator transparency, gas economics, and cryptography, making Fusaka the largest upgrade ever in terms of included EIPs.

Fusaka is named after the combination of "Fulu" (consensus layer upgrade, named after a star) and "Osaka" (execution layer upgrade, named after a Devcon location). In this article, we breakdown each improvement coming in Fusaka, explaining what changes and how it impacts you as a developer, whether you’re deploying an app, smart contracts, or building your own chain.

Key EIPs at a glance

Fusaka’s 12 EIPs address four major areas:

• Data availability & sampling: Unlocks new scaling paths for rollups and blobs.

• Cryptography & math primitives: Native precompiles for the industry-standard secp256r1 curve, expanding onchain crypto.

• Gas & execution changes: Optimizes gas costs and protocol resource allocation.

• Consensus & validator operations: Adds more predictable validator selection and efficiency.

Data Availability & Scalability

EIP-7594: Peer Data Availability Sampling (PeerDAS)

EIP-7594 introduces Peer Data Availability Sampling (PeerDAS), a major shift in how Ethereum verifies and stores blob data. Instead of every node downloading full blobs, nodes now sample small random pieces from peers and collaboratively verify that the complete dataset is available.

This lets the network handle far more data without sacrificing trust or decentralization - a prerequisite for scaling Ethereum’s data layer to hundreds of blobs per block.

PeerDAS is the first practical step toward full Danksharding. By allowing nodes to specialize in storing partial data while still validating everything, Ethereum’s throughput ceiling rises dramatically. In the long run, this mechanism could expand data capacity from hundreds of kilobytes per second to several megabytes, directly reducing Layer 2 posting costs and enabling high-throughput applications.

Rollups can post much larger batches of transactions at lower cost, allowing higher throughput and cheaper user fees. Integrations will need to adjust blob posting logic to take advantage of the expanded capacity.

EIP-7892: Blob Parameter Only (BPO) Hardforks

EIP-7892 introduces a new mechanism called Blob Parameter Only (BPO) hardforks, allowing Ethereum to adjust blob-related parameters such as target and maximum blobs per block without requiring a full network upgrade.

Instead of bundling these changes with major forks, BPO creates a lightweight, independent process for scaling blob capacity as Layer 2 data demand grows.

Before Fusaka, changing blob limits meant waiting for a coordinated hardfork, often months apart. With BPO, Ethereum can now increase blob capacity in smaller, safer steps, reacting quickly to network usage while maintaining predictable scaling. This keeps fees stable, supports continuous Layer 2 growth, and removes bottlenecks caused by infrequent, high-risk parameter changes.

EIP-7918: Blob Base Fee Bounded by Execution Cost

EIP-7918 refines Ethereum’s blob fee market by introducing a reserve price tied to the main execution gas fee. This ensures blob fees never drop below a fair baseline relative to overall network demand.

When execution gas becomes expensive but blob usage stays low, the system prevents blob prices from collapsing to near-zero (for example, 1 wei), maintaining a balanced and functional market for data availability.

Without this mechanism, the blob fee market could lose its economic signal during periods when execution dominates network activity—making it artificially cheap to post large data blobs. By anchoring blob pricing to execution costs, EIP-7918 keeps the blob market efficient, prevents under-pricing, and smooths out fee spikes when usage suddenly rises.

Dev Impact of Data Availability & Scalability

• Rollup and L2 devs can start testing higher blob posting volumes. Expect lower costs and higher throughput over time, and rollups and L2s gain room to include more onchain data per transaction without cost explosions. This unlocks new product classes previously limited by calldata or blob pricing.

• Client upgrades are mandatory. Nodes now participate in coordinated sampling rather than downloading all data, so storage and bandwidth requirements shift but the overall load becomes more balanced and scalable.

• EIP-7594 (PeerDAS) changes the proof format from blob proofs to cell proofs. Blob transaction originators (L2s, etc.) must update their software to create cell proofs instead of blob proofs. This change may break applications that send blob transactions. Read the full details and migration guide.

• Developers are encouraged to validate their rollup sequencers and DA pipelines on the Fusaka testnet before mainnet activation on December 3 2025, and verify compatibility across all client versions implementing PeerDAS and BPO scheduling.

Cryptography & Math Primitives

EIP-7939: CLZ (Count Leading Zeros) Opcode

EIP-7939 introduces a new opcode, CLZ, which counts the number of leading zero bits in a 256-bit value. It returns how many zero bits appear before the first “1” bit in a 256-bit value. For example, 0x000...001 gives 255, and 0x800...000 gives 0. It pops x from the stack and pushes the number of leading zero bits in x to the stack. If x is zero, it pushes 256.

This small but powerful addition eliminates the need for expensive bit-looping logic in Solidity when performing low-level math operations.

CLZ enables efficient implementations of integer logarithms, normalization, randomness generation, and bit-based computations — all in a single opcode. DeFi protocols, rollup contracts, and cryptographic primitives that depend on fast bit manipulation or log-scale math will benefit from measurable gas savings and cleaner logic.

Example use case:

EIP-7951: Precompile for secp256r1 Curve

EIP-7951 adds a native precompile for the secp256r1 (NIST P-256) elliptic curve, one of the most widely used cryptographic curves in WebAuthn, hardware security modules, and enterprise wallets. Until now, Ethereum only supported secp256k1 and BLS12-381, forcing developers to verify P-256 signatures off-chain or through costly custom contracts. This precompile brings fast, low-gas verification directly to the EVM.

Native support for secp256r1 unlocks seamless integration with WebAuthn and FIDO2 standards — the same cryptography used in hardware keys, browsers, and enterprise authentication systems. Wallets and apps can now verify user signatures natively onchain, reducing reliance on external relays or custodial layers. It’s a critical step for enterprise and mainstream adoption, bridging real-world identity systems with Ethereum smart contracts.

Dev Impact of Cryptography & Math Primitives

• EIP-7951 (secp256r1 precompile): Developers gain native, low-gas support for the secp256r1 (P-256) curve — the same cryptography used in WebAuthn, hardware wallets, and enterprise systems. This makes it possible to build onchain authentication, hardware key verification, and secure login flows directly in smart contracts without relying on off-chain verification or custom math libraries. It also opens the door for enterprise and institutional integrations, where P-256 is already standard, giving developers easier access to real-world identity and security systems.

• EIP-7939 (CLZ opcode): The new CLZ opcode gives developers a native, gas-efficient way to handle bit-level math, removing the need for 256-iteration loops in Solidity. This makes operations like log2, normalization, randomness, and bitmasking far cheaper and simpler to implement. Math-heavy protocols such as AMMs, rollups, oracles, and proof systems can expect significant gas savings and cleaner, faster logic using this opcode.

• Together, these upgrades extend the EVM’s cryptographic and mathematical capabilities, letting developers build more secure, more efficient, and real-world compatible applications directly on Ethereum.

Gas & Execution Changes

EIP-7823 & EIP-7883: MODEXP Bounds and Gas Cost Increase

EIP-7823 and EIP-7883 work together to redefine the cost and limits of the MODEXP (Modular Exponentiation) precompile, a function used in onchain cryptography and zk-proof verification. These updates cap the maximum allowed input size and increase gas costs to better reflect the computation required, preventing potential denial-of-service vectors from underpriced heavy math operations.

By tightening the upper bounds and adjusting pricing, Ethereum reduces the risk of computational abuse while making gas usage more predictable for complex math operations. This improves stability for contracts performing cryptographic functions such as zk-SNARK verification, modular arithmetic, and elliptic curve math.

EIP-7825: Transaction Gas Limit Cap

EIP-7825 introduces a hard upper bound for how much gas a single transaction can consume. This ensures that one large transaction can’t monopolize an entire block’s capacity or delay other transactions.

This makes block execution more consistent and reduces the risk of outlier transactions impacting network performance. Developers deploying high-compute contracts or large batch operations will need to design flows that split computation across multiple transactions instead of packing everything into one.

EIP-7934: RLP Execution Block Size Limit

EIP-7934 sets a new limit on the RLP-encoded block size, essentially capping how large a block can be once serialized. This prevents excessive block growth and improves propagation efficiency across nodes.

With this cap in place, block propagation becomes faster and more predictable, lowering the risk of propagation delays and forks. It also standardizes client behavior around large blocks, improving cross-client consistency.

EIP-7935: Default Gas Limit to 60M

EIP-7935 increases the default gas limit per block to 60 million, up from previous thresholds. This adjustment aligns with growing blob and execution data needs, giving developers and rollups more room to process complex transactions and batch operations.

The higher gas ceiling expands usable blockspace, allowing larger rollup batches, complex DeFi interactions, and higher throughput for data-heavy applications. It’s a direct benefit for developers building onchain systems that routinely hit prior block gas limits.

Dev Impact of Gas & Execution Changes

• EIP-7823 & EIP-7883 (MODEXP updates): Developers using modular exponentiation for cryptography or zk-proofs will see higher but more predictable gas costs. Update gas assumptions in verification and proof contracts to prevent underpriced calls or unexpected reverts due to new upper bounds.

• EIP-7825 (Transaction Gas Limit Cap): Apps performing large computations or complex state updates must split heavy logic across multiple transactions or adopt batching mechanisms. Frameworks handling multi-step transactions (like bridges or sequencers) should validate that execution fits within the new per-tx cap.

• EIP-7934 (RLP Block Size Limit): Infrastructure providers, explorers, and tracing tools should ensure compatibility with capped RLP block sizes. Clients and APIs relying on block serialization must handle edge cases for near-limit blocks gracefully.

• EIP-7935 (Default Gas Limit 60M): Developers benefit from more blockspace for rollup batches, DeFi interactions, and high-frequency operations. This also gives builders flexibility for data-rich protocols without risking network instability.

• Collectively, these upgrades make Ethereum’s execution environment more predictable, scalable, and secure, giving developers a smoother foundation for high-throughput dApps, L2 systems, and onchain cryptography.

Consensus & Validator Operations

EIP-7917: Deterministic Proposer Lookahead

EIP-7917 introduces a deterministic proposer lookahead mechanism for Ethereum validators. Instead of relying on short-term randomness to determine who proposes the next block, validators can now know the proposer set several slots in advance. This transparency reduces uncertainty and aligns block production more predictably across the network.

Deterministic lookahead improves validator coordination, MEV smoothing, and block relay efficiency. Builders, proposers, and relays can plan more effectively since the next proposer is known early. It also minimizes last-minute reorg attempts and improves fairness in the proposer rotation process.

EIP-7642: History Expiry & Simpler Receipts

EIP-7642 (also known as eth/69) simplifies how Ethereum handles old chain data by introducing history expiry and a new, cleaner receipt format. Older historical data can now be pruned safely after a set period, while receipts become lighter and easier to verify.

This change significantly reduces long-term state growth for nodes, lowering storage costs and improving sync times. Simpler receipts also streamline proof verification for light clients and indexing tools. Ethereum’s node operation becomes more sustainable as the chain continues to grow in size.

Dev Impact of Consensus & Validator Operations

• EIP-7917 (Deterministic Proposer Lookahead): Validator operators and staking clients should update to the new proposer selection logic to ensure consistent view of future proposer sets. MEV builders and block relays can begin planning block templates further in advance, improving latency and reducing race conditions in the block submission pipeline. Monitoring and analytics tools should surface future proposer rotations for transparency and validator coordination.

• EIP-7642 (History Expiry & Simpler Receipts): Node operators benefit from reduced disk usage and faster pruning but must verify client settings for data retention if archival access is required. Infrastructure and explorer developers should update receipt decoding and indexing pipelines to match the simplified receipt structure. Apps or proof systems that depend on old transaction receipts may need to rely on third-party archival services once history expiry takes effect.

Together, these EIPs improve validator coordination, block propagation, and long-term node sustainability — giving developers a faster, leaner, and more predictable consensus layer to build on.

A faster, smarter Ethereum for the next era

The Fusaka upgrade marks another major milestone in Ethereum’s evolution bringing together breakthroughs in data availability, gas efficiency, consensus predictability, and cryptographic power. For developers, Fusaka delivers a more efficient execution layer, a predictable fee market, and a stronger cryptographic base enabling faster rollups, lighter node operations, and new use cases like native WebAuthn verification and precision math on-chain. The result is a more scalable, secure, and developer-friendly Ethereum, ready for the next generation of high-performance applications.

Explore resources

• PeerDAS & blob scaling: Learn how to migrate to cell proofs and prepare rollups for higher blob capacity.

• Learn how teams like World scale to millions with Alchemy rollups and reach out to our team to get access.

• Start building on Ethereum: Build the future of the internet economy using Alchemy's world-class blockchain developer platform.

We’re here to help you make the most of Fusaka. Get in touch with our team, start testing on the Fusaka testnet, and build the future onchain.

FAQs

When is the Ethereum Fusaka upgrade happening?

The Fusaka upgrade is currently live on testnet and is targeting mainnet activation on December 3, 2025. Developers, node operators, and rollup teams should begin integration testing now to ensure compatibility with PeerDAS, gas schedule updates, and client behavior changes.

How do wallets and apps integrate the new secp256r1 precompile (EIP-7951)?

Fusaka introduces a native precompile for the secp256r1 (P-256) elliptic curve, the same curve used in WebAuthn, FIDO2 devices, and many enterprise authentication systems. Wallets and apps that already rely on WebAuthn for sign-in will now be able to verify signatures directly on-chain without relays or custom cryptographic libraries.

To integrate, you will reference the new precompile address and update signature verification logic to call it directly instead of performing off-chain validation. This makes secure, passwordless login and hardware-key-based transactions significantly easier to implement.

How does PeerDAS affect rollup data posting and DA pipelines?

Peer Data Availability Sampling (EIP-7594) changes how blob data is stored and validated across the network: nodes now sample pieces of blob data rather than downloading the full blob. This allows rollups to post larger batches at lower cost, improving throughput and reducing per-transaction fees.

However, rollups that currently generate blob proofs must update their software to generate cell proofs, which represent the new DA proof format. This is the primary breaking change for L2 sequencers, DA pipelines, and any tooling that prepares blob transactions.

How will Fusaka impact gas fees across Ethereum and L2s?

Fusaka includes updates that make execution costs more predictable, expands block gas capacity, and adjusts pricing for certain cryptographic operations. For users, this generally means lower L2 fees over time, since PeerDAS unlocks larger and more efficient blob posting.

For developers, gas-heavy operations like modular exponentiation become more accurately priced, so some zk-verification or math-heavy contracts may cost more per call but with less variability. Overall, Fusaka pushes Ethereum toward cheaper rollup execution and more stable fee markets across the stack.