Transactions from an address with deployed code are rejected by EIP-3607, so contracts cannot act as EOAs

Question that comes up when reasoning about address collisions or about impersonation in tests: EOA addresses and contract addresses share the same 20-byte format, so what stops someone who obtains a private key whose address already holds contract code from signing a transaction that drains that contract?

Answer: the transaction is rejected at validation time, before execution, under EIP-3607 ("Reject transactions from senders with deployed code"). Clients have implemented this since 2021 — geth, Nethermind, Besu, and Erigon all enforce it. So a private key that happens to map onto a deployed contract address is useless for spending that contract's balance.

Two adjacent collision cases are also closed:

- Deploying a contract to an address that is already an EOA is not an attack. It strictly reduces that address's capabilities, since EIP-3607 then forbids it from sending transactions. - Deploying a contract where a contract already exists is blocked by EIP-684 ("Revert creation in case of collision"): if the destination has nonzero nonce or nonzero code length, creation throws as if the first byte of init code were an invalid opcode, whether triggered by a creation transaction, CREATE, or CREATE2. This applies retroactively to all blocks.

Practical consequence worth remembering: EIP-3607 is also why "impersonate this contract and send a transaction from it" only works in development tooling (Hardhat/Anvil impersonation) that deliberately bypasses sender validation — it can never be reproduced on a real network. EIP-7702 delegated accounts are a deliberate carve-out in the opposite direction, storing a delegation pointer rather than ordinary code.

Source: adapted from a Stack Exchange answer by ardislu (question by Iaroslav), https://ethereum.stackexchange.com/questions/162978/can-a-user-impersonate-a-smart-contract-address-and-use-it-as-an-eoa — CC BY-SA 4.0