Ethereum SELFDESTRUCT After EIP-6780: What It Actually Deletes

Calling SELFDESTRUCT sounds like pressing a delete button. On modern Ethereum, that mental model is usually wrong. Since the Cancun execution upgrade, an old contract that executes the opcode normally sends away its Ether and stops the current call, while its code, storage, and account remain. This distinction belongs in your blockchain basics toolkit because stale assumptions can break shutdown plans, redeployment systems, and incident response.

This guide explains the final EIP-6780 rules, the narrow same-transaction exception, and safer design choices. It also separates today's consensus behavior from later proposals that can still change.

What SELFDESTRUCT does after Cancun

Think of a smart contract as a shop with a cash drawer, operating manual, and filing cabinets. Before Cancun, SELFDESTRUCT could schedule the shop for removal and send its Ether to a beneficiary. Under EIP-6780, an established shop can empty its cash drawer, but the building, manual, and files stay in place.

For a contract not created in the current transaction, executing SELFDESTRUCT now:

1. halts the current execution frame;
2. transfers the contract's full Ether balance to the beneficiary;
3. does not delete its code, storage, or account; and
4. gives no SELFDESTRUCT gas refund.

The opcode still has observable effects. It can move Ether and halt execution. It just is not a general-purpose contract deletion mechanism anymore.

This is a network rule, not a compiler switch. The Solidity documentation notes that choosing a different --evm-version does not restore pre-Cancun behavior on a chain that has activated Cancun.

The same-transaction exception

EIP-6780 preserves the earlier behavior when a contract executes SELFDESTRUCT in the same transaction in which it was created. In that narrow case, the contract's code, storage, and account can still be cleared at transaction finalization, and its balance is sent to the beneficiary.

“Same transaction” is stricter than “same block” or “recently deployed.” A factory can create a temporary child and have that child self-destruct before the factory transaction ends. A contract deployed in transaction A and destroyed in transaction B is already an established contract, even if both transactions land in one block.

The exception exists partly for ephemeral contracts and counterfactual patterns that never need persistent state. It should not be treated as a promise that the opcode will remain a permanent lifecycle tool. EIP-6049 formally deprecated SELFDESTRUCT, and Solidity has warned about its use since version 0.8.18.

Situation	Ether balance	Code and storage	Account deletion
Contract existed before this transaction	Sent to beneficiary	Preserved	No
Contract created and self-destructed in this transaction	Sent to beneficiary	Cleared under current rules	Yes, under current rules
Call reverts later in its transaction scope	State effects revert	Preserved	No committed deletion

Why Ethereum changed the opcode

Deleting one account looks simple from an application perspective, but it creates broad state-management work for clients. EIP-6780 explains that future state structures such as Verkle trees spread an account across multiple keys, making arbitrary deletion more complicated. Restricting deletion removes that dependency while retaining a narrow temporary-contract path.

The gas incentive had already changed. EIP-3529 removed the SELFDESTRUCT refund and reduced storage-clearing refunds. Old advice about deploying gas tokens or destroying contracts to reclaim gas is therefore obsolete.

There is also a history-versus-state distinction. Even when the exception clears current state, the transaction and prior contract activity remain part of blockchain history. SELFDESTRUCT is not equivalent to securely erasing a file from every node, indexer, archive, or data provider.

CREATE2 and metamorphic contracts after EIP-6780

Some older systems combined CREATE2 with SELFDESTRUCT to replace code at a deterministic address across separate transactions. The sequence was: deploy, destroy, then deploy different runtime code to the same address. EIP-6780 breaks that metamorphic upgrade pattern for established contracts because their code and nonce are not cleared.

This does not change the address formula described in our CREATE2 guide. It changes whether the destination becomes eligible for creation again. If an address still has code or a nonzero nonce, the EVM's creation-collision rule prevents overwriting it.

For upgrades, use an explicit architecture whose authority and storage rules can be audited. Proxy contracts keep a stable address while delegating execution to an implementation. That model carries its own admin, initialization, and storage-layout risks, but it exposes the upgrade mechanism instead of depending on obsolete destruction semantics.

Safer ways to deactivate a contract

Most applications do not need deletion. They need a controlled way to stop risky actions while preserving evidence and user exit paths.

Pause selected operations

A pause flag can block deposits, borrowing, minting, or other sensitive functions while leaving withdrawals or recovery functions available. Secure the authority with a multisig or governance process, define exactly which functions stop, and test both pause and unpause paths.

Permanently disable behavior

If shutdown must be irreversible, the contract can set a one-way state flag that causes relevant functions to revert. Solidity's documentation recommends deactivation through internal state rather than relying on SELFDESTRUCT. Publish the conditions and confirm that no alternate entry point, delegated call, or privileged role bypasses the flag.

Migrate explicitly

A migration can announce a successor address, freeze new activity, and let users withdraw or claim positions through documented steps. Do not silently assume balances, approvals, or integrations move with the code. Each asset and dependency needs its own migration analysis.

Use a reviewed proxy when upgrades are required

An upgradeable proxy is appropriate only when ongoing code replacement is an intentional trust assumption. Verify the effective admin, delay, multisig threshold, initializer state, storage compatibility, and monitoring. “Upgradeable” is not automatically safer than immutable deployment.

Risks and audit checks

• False shutdown: a function calls SELFDESTRUCT, but the established contract's code and storage remain callable afterward.
• Forced Ether movement: the opcode can still transfer the executing contract's Ether balance. Trace the beneficiary and authorization.
• Delegatecall reachability: Solidity warns that a contract can execute SELFDESTRUCT through delegated code even when its own source does not contain the instruction.
• Chain differences: EVM-compatible networks activate upgrades on different schedules and may implement different rules. Confirm the target chain and fork state.
• Constructor edge cases: same-transaction destruction remains special under current rules. Test factories, nested creation, reverts, and balance flows rather than extrapolating from established contracts.
• Unfinalized proposals: EIP-8246 was in Last Call on October 2, 2026 and proposed removing the remaining same-transaction Ether-burn behavior. It is not the basis for current mainnet behavior unless a future network upgrade includes and activates it.

An auditor should search source and bytecode paths, not just public function names. Review direct opcode use, inline assembly, libraries reached by DELEGATECALL, factory-created children, beneficiary selection, and behavior under the target fork.

Developer checklist

• Identify every direct and delegated path that can execute SELFDESTRUCT
• Record whether the executing contract was created earlier in the same transaction
• Test code, storage, nonce, and balance before and after the call
• Remove assumptions about SELFDESTRUCT gas refunds
• Reject cross-transaction CREATE2 redeployment as an upgrade plan
• Design pause, exit, migration, or proxy controls explicitly
• Verify the fork rules on every supported EVM chain
• Track proposal status without presenting draft behavior as active consensus

FAQ

Does SELFDESTRUCT delete a contract on Ethereum today?

Usually no. For a contract that existed before the current transaction, it transfers Ether to the beneficiary and halts the frame but leaves code, storage, and the account intact.

Can I redeploy new code to the same CREATE2 address?

Not by destroying an established contract in one transaction and redeploying in a later transaction. EIP-6780 preserves the code and nonce, so creation collides. Same-transaction temporary patterns are a narrow exception, not a general upgrade system.

Does SELFDESTRUCT refund gas?

No. EIP-3529 removed the refund. Clearing qualifying storage can still have separate refund rules, but destroying a contract is no longer a gas-refund strategy.

Can a compiler setting recover the old behavior?

No. The activated network fork determines opcode semantics. Compiler EVM targets affect generated bytecode and compatibility, not the consensus rules that nodes execute.

Treat shutdown as a feature, not an opcode

After EIP-6780, SELFDESTRUCT is mostly a balance transfer plus an execution halt, with one same-transaction creation exception. Existing contracts do not vanish, CREATE2 cannot overwrite them across transactions, and no destruction refund remains. Build lifecycle controls directly: pause carefully, preserve user exits, make migrations explicit, and audit upgrade authority.

This article is educational, not financial advice. Smart-contract actions can be irreversible and crypto assets are volatile; test against the correct chain rules, use only funds you can afford to lose, verify current primary documentation, and do your own research (DYOR).

Primary sources

• EIP-6780: SELFDESTRUCT only in same transaction
• EIP-6049: Deprecate SELFDESTRUCT
• EIP-3529: Reduction in refunds
• Solidity documentation: Deactivate and Self-destruct
• EIP-8246: Remove SELFDESTRUCT Burn (proposal status)