EIP-6780: declawing SELFDESTRUCT
SELFDESTRUCT could erase a contract's code and free its address — which let a different contract be redeployed at the same address (a 'metamorphic' contract) and made 'a contract can just vanish' a headache for Ethereum's whole state design. Removing it outright would break things, so EIP-6780 restricts it: it only truly deletes if the contract was created in the same transaction.
- contracts, code & storage
- CREATE2
Cancun, March 2024. Two earlier chapters left a loose thread. The CREATE2 chapter warned about metamorphic contracts — putting different code at the same address — and the refund reduction already stripped SELFDESTRUCT’s gas refund. This chapter ties the thread off. SELFDESTRUCT was one of the EVM’s most dangerous instructions: a single opcode that could erase a contract entirely — code gone, storage cleared, address freed. That power enabled a genuine attack surface and quietly blocked Ethereum’s long-term plans. EIP-6780 defuses it without breaking the contracts that legitimately use it. Let’s derive it.
The problem: a contract could truly vanish
Original SELFDESTRUCT did three drastic things at once: it deleted the contract’s code, cleared its storage, and freed the address — sending any remaining balance to a target. Freeing the address is the dangerous part, because CREATE2 lets you deploy to a chosen address. Chain them and you get a metamorphic contract A contract that changes its code at a fixed address: deploy code via CREATE2, SELFDESTRUCT to free the address, then CREATE2 again at the same address with different code. Breaks the assumption that an address's code is immutable. : deploy, self-destruct, redeploy different code at the same address. An address someone audited or trusted could silently become something else entirely.
There’s a second, quieter cost. An opcode that can delete arbitrary state in one shot is a nightmare for the roadmap toward statelessness A direction for Ethereum where clients verify blocks using compact proofs (witnesses) of just the state a block touches, rather than holding all state. Verkle trees are the enabling structure. An opcode that can delete whole accounts makes generating and reasoning about these proofs far harder. and Verkle trees: if any account can wink out of existence, generating and reasoning about state witnesses gets much harder. “A contract can vanish” complicated everything downstream.
→ Step 2: keep the full power only where it’s safe.
EIP-6780: full delete only in the creating transaction
The insight is that the only genuinely safe time to fully delete a contract is when it was just created and never left the transaction — a common pattern for a throwaway helper deployed and torn down within one call. So EIP-6780 keeps the complete “delete code + clear storage + free the address” behavior only if the contract was created in the same transaction as the SELFDESTRUCT. In every other case — the normal one, where a long-lived contract self-destructs later — SELFDESTRUCT now only transfers the balance to its target and leaves the code and storage in place. The contract keeps existing.
→ Step 3: yes — and the roadmap breathes easier.
The payoff: no more shape-shifting addresses
The metamorphic trick needed SELFDESTRUCT to free the address across transactions so a later CREATE2 could claim it. Now, when a deployed contract self-destructs in a later transaction, its code stays and the address remains occupied — so CREATE2 can’t put new code there. Metamorphic contracts are effectively dead: an audited address’s code can no longer be swapped out from under you. And because contracts no longer vanish, the state’s semantics get dramatically simpler, clearing an obstacle on the path to statelessness. Meanwhile, the legitimate create-and-destroy-in-one-transaction pattern is untouched, so nothing real breaks.