EIP-684 Fail contract creation on address collision (Revert creation in case of collision)
Final · Security & privacy · EIP status Final · created 2023-03-20
Contract creation must fail if the target address already has a nonce or code. This prevents attacks that change deployed code after the fact.
Why it is needed
The core premise of smart contracts is that deployed code does not change. Under the existing rules, however, nothing blocked re-'creating' an account at an address that already has code. An attacker with enough computing power could deploy contract code at an address, later trigger creation at the same address again, and replace the stored code with arbitrary other code. That would allow stealing funds or planting other malicious behavior. This EIP makes creation fail outright if the target address already has a nonzero nonce or code, enforcing the immutability of deployed code as a protocol rule.
What changes
Today
- Account creation can still be attempted at an address that already has code
- An attacker with enough computing power can replace deployed code with different code
- The immutability of deployed code is not guaranteed by the rules
After EIP-684
- Creation must fail if the target address has a nonzero nonce or code
- The same rule applies to every creation path, including creation transactions, CREATE, and CREATE2
- The immutability of deployed code is enforced at the protocol level
Who is affected
- Users: The risk that the code of a contract you use could later be replaced with different code goes away.
- Contract and app developers: The protocol guarantees that the code at a deployed address stays as it is, so you no longer need to worry separately about address collision attacks.
- Client teams: This is an execution layer change, so it must ship in a hard fork, and the rule must be implemented to apply retroactively to all existing blocks.
In depth
Collision conditions and failure mode
Whenever contract creation is attempted, whether by a creation transaction, the CREATE opcode, the CREATE2 opcode, or for any other reason, creation MUST fail if the destination address has a nonzero nonce or a nonzero code length. The failure is handled as if the first byte of the init code were an invalid opcode. In other words, no separate exception path is introduced, and the existing execution failure semantics are reused as is.
Applies retroactively to all existing blocks
The rule MUST be applied retroactively to all existing blocks. It does not turn on only after a particular fork block, and the same collision handling rule applies across the entire chain history. At the same time, this change is an execution layer upgrade, so it requires a hard fork.
The attack it prevents
The premise that code does not change is the core of smart contracts. However, with enough computing power, an attacker can replace the code stored at an address with different code. The method is to deploy contract code first, then later 're-create' an account at that address to swap the code arbitrarily. This makes malicious acts such as stealing funds possible. This EIP is a security upgrade that blocks that creation path itself and enforces the immutability of deployed code.
Test cases
Two accounts are set up through the genesis allocation. 0xd0bBEc6D2c628b7e2E6D5556daA14a5181b604C5 has a balance of 1 ether, nonce 0, and no code, and 0x7658771dc6Af74a3d2F8499D349FF9c1a0DF8826 has a balance of 0, nonce 1, and code 0xB0B0FACE. In the first transaction sent by the externally owned account 0xd0bBEc6... (hash 227bcc6959669226360814723ed739f1214201584b6a27409dfb8228b8be5f59), the contract creation made without a salt must revert.
Status and call decision
The status of this EIP is Final. At ACDT #96 on September 14, 2026, it was decided to merge legacy test PR #18 and revert collision handling to the Yellow Paper and EIP-684 approach. However, collision handling for the Block Access List (BAL) is left undefined until EIP-8253 in Hegota is settled.