EIP-7610 Last Call EL

Revert creation in case of non-empty storage

Authors: ,

Canonical data: /latest/eips/7610.json

Revert contract creation if address already has the non-empty storage

Timeline

Glamsterdam

Jochem Brouwer

Considered for Inclusion · Jan 29, 2026 · ACDE #229

Jan 29, 2026 · ACDE #229

Proposed

EIP Created Feb 2, 2024

Key Benefits

● Mitigates issues stemming from contract deployment over existing storage.
● Makes sure app developers cannot make this mistake and provides correct errors if such a tx is submitted.

Trade-offs & Considerations

No trade-offs documented yet.

Stakeholder Impact

End Users

No direct impact on regular users.

Application Developers

Making sure devs cannot deploy contract on incorrect address with proper error handling.

Wallet Developers

No changes to wallets.

Tooling / Infrastructure

Contract development tooling needs to update and handle errors correctly

Layer 2s

L2s can benefit from the improvement following the change in their implementations.

Stakers & Node Operators

No impact on stakers and nodes.

CL Client Developers

No change to consensus layer.

EL Client Developers

New condition needs to implement the check in EL clients.

Abstract

This EIP causes contract creation to throw an error when attempted at an address with pre-existing storage.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

If a contract creation is attempted due to a creation transaction, the CREATE opcode, the CREATE2 opcode, or any other reason, and the destination address already has either a nonzero nonce, a nonzero code length, or non-empty storage, then the creation MUST throw as if the first byte in the init code were an invalid opcode. This change MUST apply retroactively for all existing blocks.

This EIP amends EIP-684 with one extra condition, requiring empty storage for contract deployment.

This EIP will not affect EIP-7702, since the authority's nonce is always incremented after an authorization is applied, which conflicts with the condition required for contract deployment.

Rationale

EIP-684 defines two conditions for contract deployment: the destination address must have zero nonce and zero code length. Unfortunately, this is not sufficient. Before EIP-161 was applied, the nonce of a newly deployed contract remained set to zero. Therefore, it was entirely possible to create a contract with a zero nonce and zero code length but with non-empty storage, if slots were set in the constructor. There exists 28 such contracts on Ethereum mainnet at this time.

Backwards Compatibility

This is an execution layer upgrade, and so it requires a hard fork.

Test Cases

There exists quite a number of tests in the ethereum tests repo as well as in the execution spec tests, which test the scenario of deployment to targets with non-empty storage. These tests have been considered problematic in the past; Reth and EELS both intentionally implement a version of the account reset solely to pass the tests. Py-evm declared the situation impossible and never implemented account reset.

Refilling the existing tests will provide sufficient coverage for this EIP.

Security Considerations

This EIP is a security upgrade: it enforces the immutability of deployed code.