SELFDESTRUCT does not generally erase an existing Ethereum contract
EIP-6780 changed what the opcode does. Contract age within the transaction matters, so an old explanation of deletion can misdescribe present execution rules.
Full analysis is selected. Choose Quick brief to scan the key points first.
WFN QUICK BRIEF · UNDER 1 MIN
The short version
MODE 2 OF 2
What the primary record establishes
Under EIP-6780, SELFDESTRUCT called outside the transaction in which the contract was created halts the execution frame and transfers the account’s Ether balance, but does not delete its code, storage or account. The specification retains a separate same-transaction creation exception. Ethereum EIP-6780 — SELFDESTRUCT only in same transaction ↗
What the distinction changes
This distinction matters when a recovery procedure says a contract can simply be removed. A transaction containing the opcode is not, by itself, evidence that the contract’s stored state disappeared. A review must examine the rule set and the actual execution circumstances.
What to check before drawing a conclusion
For an existing integration, inspect the target chain’s activated rules, contract creation transaction and execution trace. Do not assume all EVM-compatible networks adopted identical semantics at the same time. Check upgrade and recovery assumptions against the deployed system.
Quick Brief is a reading aid. The full article and source trail stay on this page.
WFN STORY COMPASS
Choose your reading angle
Move between the reported record, market context and open questions. Status labels keep claims distinct from findings.
All context layers are visible. Choose a lens to jump to that part of the story.
Original WFN vector illustrationWFN · 18 October 2026
Editorial noteSource-based explanation with original WFN analysis. Historical records retain their dates; numerical examples are illustrative. The original vector illustration is conceptual and is not documentary evidence.
WFN REALITY LEDGER
What is on the record?
Primary-source explainer
Primary-source explainer
Primary record / reference periodEIP-6780 Final specification; checked 18 October 2026
The linked source supports the documented record; WFN interpretation and illustrative examples are separate.
EIP-6780 changed what the opcode does. Contract age within the transaction matters, so an old explanation of deletion can misdescribe present execution rules.
01 · VERIFIED RECORD
What the primary record establishes
Under EIP-6780, SELFDESTRUCT called outside the transaction in which the contract was created halts the execution frame and transfers the account’s Ether balance, but does not delete its code, storage or account. The specification retains a separate same-transaction creation exception. Ethereum EIP-6780 — SELFDESTRUCT only in same transaction ↗
The EIP warns that designs relying on destroying and redeploying a contract at the same address across transactions no longer work as before. It also says the opcode remains deprecated and discourages its use in new contracts. Ethereum EIP-6780 — SELFDESTRUCT only in same transaction ↗
02 · WFN EDITORIAL ANALYSIS
What the distinction changes
This distinction matters when a recovery procedure says a contract can simply be removed. A transaction containing the opcode is not, by itself, evidence that the contract’s stored state disappeared. A review must examine the rule set and the actual execution circumstances.
Nor does transferring an Ether balance prove that every token balance or external claim has been recovered. A service should identify the asset, relevant contract state and beneficiary rather than label an operation complete because one account balance changed.
03 · REVIEW POINTS
What to check before drawing a conclusion
For an existing integration, inspect the target chain’s activated rules, contract creation transaction and execution trace. Do not assume all EVM-compatible networks adopted identical semantics at the same time. Check upgrade and recovery assumptions against the deployed system.
WFN’s analysis concerns the standard’s stated behaviour. It is not a security audit of a contract or a transaction recipe. A promised deletion, migration or recovery should be verified through the actual post-transaction state and documented asset accounting.
