What Changed With EIP-6780? Selfdestruct on Ethereum Explained

EIP-6780 is an Ethereum protocol change, activated in the March 2024 Dencun upgrade, that stripped the SELFDESTRUCT opcode of most of its original power. Instead of always deleting a contract's code and clearing its storage, SELFDESTRUCT now only does that when it's called in the same transaction that created the contract. In every other case, it just sends the contract's remaining ETH balance to a target address and leaves the code and storage untouched.

To understand why this mattered, it helps to know what the opcode used to do.

What SELFDESTRUCT used to do

From Ethereum's earliest days, SELFDESTRUCT (originally called SUICIDE) was the one instruction a smart contract could use to erase itself. A developer would write a function — often gated behind an admin check — that called this opcode. When executed, it would:

1. Send any remaining ETH balance to a specified address.
2. Delete the contract's bytecode from the chain's state.
3. Clear all of the contract's storage slots.
4. Refund the caller a chunk of gas, because deleting state was considered a public good — it shrank the amount of data every node had to store.

This made SELFDESTRUCT useful for upgradeable proxy patterns, one-time-use factory contracts, and emergency kill switches. It was also, notoriously, a building block for "metamorphic contracts" — contracts that could self-destruct and then be redeployed at the exact same address with entirely different code, which created subtle trust problems for anything that assumed an address's logic was fixed once verified.

Why it needed to change

Two separate pressures collided here. First, the gas refund for self-destructing was already reduced by EIP-3529 (part of the London upgrade) because refunds were being gamed to artificially lower gas costs in unrelated transactions. Second, and more fundamentally, Ethereum's long-term roadmap depends on being able to reason confidently about how state changes over time, particularly for the planned migration to Verkle trees and any future state-expiry scheme. An opcode that could instantly wipe an account's storage from anywhere, at any time, made that migration harder to implement safely and complicated tooling that indexes contract state.

There was also a more immediate practical concern: full deletion mid-life let a contract's code disappear while other contracts still held references to it, or let addresses be "reused" with different logic after the fact — an edge case auditors and security tools had to account for indefinitely.

What EIP-6780 actually changed

The fix was narrower than removing the opcode entirely, which would have broken a large amount of deployed code that calls it. Instead, the behavior was split based on timing:

Scenario	Before EIP-6780	After EIP-6780
SELFDESTRUCT called in the same transaction as contract creation	Sends balance, deletes code and storage	Sends balance, deletes code and storage (unchanged)
SELFDESTRUCT called in a later transaction, after the contract has existed for a while	Sends balance, deletes code and storage	Only sends the ETH balance — code and storage remain
Gas refund for calling it	Small refund	No refund

In practice, this means the "kill switch" pattern that many contracts implemented — deploy once, allow an admin to self-destruct later if something goes wrong — no longer clears the contract's bytecode or storage. The contract's logic stays on-chain permanently once it has processed even a single transaction after deployment. Only contracts that self-destruct within their own creation transaction (a narrow pattern used by some factory and CREATE2 tricks) retain the full wipe behavior.

Impact on existing contracts

Most everyday users won't notice any difference — this is not something that shows up in a wallet or a dapp interface. It matters mainly to developers and auditors:

• Upgradeable proxies that relied on self-destructing an implementation contract to "revoke" old logic now need a different pattern, since the old contract's code will persist.
• Metamorphic contract tricks (self-destruct then redeploy different code to the same address) mostly stopped working for contracts that had already processed transactions, closing off a known source of address-reuse confusion — though the same-transaction case theoretically still allows it under narrow conditions.
• Gas estimation tools and block explorers had to update their models, since the old flat gas refund assumption for self-destruct calls no longer applied.
• Auditors reviewing older contracts still need to understand the pre-Dencun behavior, because contracts deployed before the upgrade that call SELFDESTRUCT will behave differently today than they did when originally written and tested.

This is a good example of how Ethereum evolves: rather than an abrupt removal, an opcode's semantics were narrowed in a way that's mostly invisible to end users but meaningfully changes what developers can rely on. It's part of a broader cleanup effort — sometimes called "the Purge" — aimed at reducing the amount of historical baggage nodes have to carry and reason about. If you want the fuller context on how Ethereum's state and storage design is evolving, our piece on state bloat covers the related problem this change was partly aimed at easing.

Bottom line

EIP-6780 didn't remove SELFDESTRUCT, it defanged it. Outside of the same-transaction edge case, calling it today only moves ETH — it no longer deletes a contract's code or storage. If you're a user, this changes nothing about how you interact with smart contracts. If you're a developer maintaining contracts written before March 2024, it's worth re-checking any logic that assumed a working "delete this contract" function, because that function quietly stopped deleting anything.