Ethereum Smart Contracts: Full Update on Fusaka and Glamsterdam

Ethereum Smart Contracts: A Major Network Update

Ethereum smart contracts just went through one of the biggest infrastructure updates in the network's history. 

The Fusaka upgrade activated on the Ethereum mainnet on December 3, 2025, and it changed how smart contracts execute, how much data blocks can carry, and how developers write and deploy code on the network. 

This update explains what shifted, why it matters for anyone building or using Ethereum smart contracts, and what comes next on the roadmap toward Glamsterdam and Hegota.

Whether you run a validator node, deploy DeFi protocols, or simply hold assets secured by Ethereum smart contracts, the changes bundled into this release touch gas economics, contract structure, and the pace of future upgrades. 

The sections below walk through each piece in order, starting with what actually shipped in Fusaka.

What Changed With the Fusaka Upgrade

Fusaka is the largest upgrade Ethereum has shipped in terms of the number of ETH Improvement Proposals it bundled together, combining twelve EIPs across the consensus and execution layers, according to Alchemy's developer breakdown. 

The headline feature is PeerDAS, or Peer Data Availability Sampling, which lets validator nodes verify blob data without downloading every byte of it themselves.

For Ethereum smart contracts specifically, Fusaka raised the code size limit through EIP-7907 and added the CLZ opcode under EIP-7939, giving developers a more efficient way to run certain math operations and trim bytecode. 

The upgrade also introduced a block size cap and a per-transaction gas cap to keep larger blocks from overwhelming validators as throughput increases, as detailed in Consensys's technical overview of the release. 

Client teams also shipped memory and internal-logic improvements at the software level, changes that are invisible to everyday users but that make node operation more resilient as network activity grows.

Ethereum Smart Contracts and the EVM Object Format

One of the most consequential pieces of this update for builders is the EVM Object Format, or EOF, which restructures how Ethereum smart contracts separate code from data. 

Instead of a single blob of bytecode, EOF introduces distinct sections for code, data, and metadata, which makes contracts easier to validate before they run and reduces the chance of certain runtime errors slipping through.

Practically, this means static analysis tools can inspect a contract's structure before execution rather than only at runtime, and it opens the door to faster JIT-style execution in future client implementations. 

Developers deploying complex DeFi protocols, oracles, or account-abstraction wallets get more predictable gas costs and fewer edge cases where a contract behaves unexpectedly on-chain. 

Following Fusaka, two additional Blob Parameters Only forks are scheduled to keep expanding blob throughput without requiring a full hard fork each time, as outlined by CoinGecko's Fusaka explainer.

What Comes Next: Glamsterdam and Hegota in 2026

Fusaka was explicitly framed by client teams as groundwork for the next phase of Ethereum's roadmap. 

Glamsterdam, targeted for the first half of 2026, centers on Enshrined Proposer-Builder Separation under EIP-7732, a change meant to formalize how blocks get built and reduce centralization risk in that process. 

Glamsterdam is currently in its testnet and hardening phase.

A second upgrade, tentatively named Hegota, is already being discussed for later in 2026, signaling that the Ethereum Foundation's protocol team is shifting toward a faster, more frequent release cadence instead of the older pattern of one large yearly upgrade. 

Longer-term roadmap items grouped under the Verge, the Purge, and the Splurge continue to target lighter stateless clients, protocol simplification, and account-abstraction improvements. 

Anyone tracking the official schedule should check ethereum.org's roadmap page directly, since upgrade names and included EIPs can shift as proposals move through testnets. 

Developers building against Ethereum smart contracts today should treat these names as directional rather than final until each proposal clears its client-team review and lands on a public testnet.

Gas Limits, Security, and Developer Impact

Bigger blocks and higher gas limits sound purely positive for throughput, but they also raise the amount of data validators must process per block. 

Fusaka's safety measures, the block size cap under EIP-7934 and the transaction gas cap under EIP-7825, exist specifically to prevent oversized blocks from becoming a denial-of-service vector while the network absorbs more activity. 

This balance between scaling and security is a recurring theme across the entire Ethereum roadmap.

For teams shipping Ethereum smart contracts today, the practical checklist looks like this: retest gas assumptions against the new opcode and code-size limits, monitor rollup fee behavior since Layer 2s benefit directly from expanded blob capacity, and watch official client release notes rather than relying on secondary summaries. 

Contract addresses, balances, and existing deployments are unaffected by the upgrade itself; no migration action is required from holders or from most application developers. 

Live contract activity on the new format can be verified directly on Etherscan, Ethereum's official chain explorer.

Table: Ethereum protocol upgrade status as of August 2026, compiled from client-team meeting notes and the official roadmap.

Impact on DeFi, Layer 2s, and Auditing

Rollup teams are among the biggest beneficiaries of this update. 

Expanded blob capacity from PeerDAS means Layer 2 networks can post more transaction data to Ethereum's base layer at a lower cost per byte, which typically translates into cheaper fees for end users on networks like Arbitrum, Optimism, and Base. 

Since most everyday DeFi and NFT activity now happens on these rollups, the effect of the upgrade is often felt indirectly rather than through a direct interaction with Ethereum smart contracts on layer one.

Auditors and security researchers have a new variable to account for as well. 

The EVM Object Format changes how bytecode is structured, so static analysis tools and formal verification frameworks need updated support to fully parse EOF-formatted contracts. 

Teams running audits on new deployments should confirm their tooling vendor has published EOF compatibility notes before treating an audit as complete, since older parsers built for legacy bytecode may not flag every issue in a contract compiled against the new format. 

Wallet infrastructure is shifting too, with EIP-7951 adding native secp256r1 curve support that unlocks passkey and hardware-security-module-based signing for smart accounts, reducing reliance on seed phrases for some wallet designs.

Expert Opinion

Protocol researchers following the Ethereum core developer calls describe Fusaka as an infrastructure release rather than a user-facing one, built to make later upgrades safer to ship. 

Analysts at Consensys have characterized the EVM Object Format work in Fusaka as groundwork that later upgrades will build on rather than a finished feature in itself. 

The broader expectation among client teams is that Ethereum smart contracts will keep getting cheaper to deploy and more predictable to audit as EOF adoption spreads through the tooling ecosystem over the next several release cycles.

Disclaimer

This article is for informational purposes only and does not constitute financial, investment, or technical advice. Ethereum protocol details, upgrade timelines, and EIP scopes can change before mainnet activation. Readers should verify current status through official Ethereum channels and consult a qualified professional before making decisions based on network upgrades.