The EOF deployment risk in Ethereum’s Fusaka upgrade

The 23% contract deployment failure rate on devnet reveals implementation instability within the EVM Object Format. Developers face significant client development impacts since most clients integrated EOF-supporting code for the expected Osaka rollout during recent testing. All client teams must expend massive effort to unwind architectural changes for code validation and parsed structures. Besu and EVMONE are adapting to recent spec changes, while Nethermind and Geth work on state test issues. EELS has started implementation, but no updates exist for Reth or EthJS.

The failure is real.

The Complete EOF plan includes all proposed features and maintains bans on code and gas introspection. This path increases the complexity for developers who must handle new paths for EOF contract creation. If the community shifts to "Introspecting EOF" instead, teams must implement the InitcodeTransaction type and an EOF creation precompile. This pivot avoids broader tooling impacts but still demands work for TXCREATE integration. Minimal EOF uses Shanghai-era proposals and includes EIP-7698 to resolve limitations where developers could not append extra data to containers in deployment scripts.

Protocol fragmentation and complexity

Piecemeal adoption of EOF features through separate EIPs increases the risk of a convoluted EVM. Staggered rollouts amplify scheduling risks because EVM changes often fall behind other upgrades. This fragmentation makes structural ossification more likely as momentum shifts elsewhere. Different versions of the EVM will coexist in the state, which makes reasoning about execution rules difficult. The complexity of managing these versions will burden client teams.

Can the community reach a consensus before the next hard fork?

Version management is difficult. The EOF container uses a version parameter to avoid backward compatibility issues, such as those seen in EIP-3540. EIP-7960 adds a type parameter to the types section, allowing the interpreter to identify code section types. This addition allows a contract to dispatch to different variants of the interpreter, such as running pure EVM64 code for heavy computation. However, if a type is not of a known type, validation fails. EIP-7823 changes the MODEXP precompile to match real computational costs. It raises the minimum charge from 200 to 500 gas and removes the one-third discount from EIP-2565. It also increases costs more sharply when the exponent input exceeds 32 bytes.

Operational coordination risks

The three-phase structure of the Fusaka upgrade creates coordination risks across 35 days. Because the upgrade includes a mainnet hard fork on December 3, 2025, followed by BPO1 on December 9 and BPO2 on January 7, any validator failure could split the blockchain. Because the Fusaka upgrade relies on three sequential upgrade events, any validator failure during these stages creates a risk of chain splits that threaten transaction finality and require reconciliation across custody and asset management operations. You should monitor block finalization in real-time to ensure stable consensus.

Deployment fails often.

Technical limits remain strict.

EIP-7825 caps gas at 16,777,216 per transaction to prevent single transactions from consuming an entire block. This protects against DoS attacks and improves network stability. EIP-7935 asks clients to test higher limits on devnets and ship 60 million as the default. The limit for RLP-encoded execution blocks is 10 MiB. This 10 MiB limit includes a 2 MiB safety margin for beacon-block framing. BPO1 increases the target number of blobs from 6 to 10 and the maximum from 9 to 15. BPO2 increases these target and maximum values to 14 and 21. These adjustments allow for flexible capacity management.

The 23% failure rate proves the instability of the current EOF implementation for the network.