For an Ethereum contract created in an earlier transaction, SELFDESTRUCT no longer means that its code disappears. It can move the ETH balance while leaving the contract itself in place.
| What you need to know |
|---|
| For a contract created in an earlier transaction, SELFDESTRUCT preserves code, storage and the account. |
| The operation transfers the contract's entire ETH balance to its target; targeting itself leaves that balance unchanged. |
| Deletion remains possible when creation and SELFDESTRUCT occur within the same transaction. |
| Neither branch receives a SELFDESTRUCT gas refund under the rules stated in EIP-6780. |
Start with an existing contract that holds ETH and has stored application data. Under EIP-6780’s specification, calling SELFDESTRUCT with a different beneficiary transfers the contract’s entire ETH balance. Its code, storage and account are retained. The familiar opcode name describes more destruction than this branch of the rules actually performs.
That matters when reading an old design rather than just an individual transaction. A diagram showing a contract being removed and replaced may depend on behaviour that the current rules do not provide. Emptying its balance does not erase its stored data or free the address for an unrestricted replacement.
The exception belongs to a transaction, not a block
A contract created and destroyed within the same transaction follows the exception: SELFDESTRUCT can still delete it. Creation earlier in the same block is not enough. Two transactions remain two transactions, however closely together they appear in a block explorer.
This gives a simple pair of cases. Contract A was deployed yesterday and invokes SELFDESTRUCT today: its code and storage remain. Contract B is created and invokes the opcode during one transaction: the deletion exception applies. These are illustrations of the rule, not reports of particular deployments.
The beneficiary also changes the balance result. In the existing-contract branch, targeting the contract’s own address leaves its balance unchanged. In the same-transaction creation exception, the older destruction behaviour applies, including burning the balance when the beneficiary is the contract itself.
Neither path restores a SELFDESTRUCT gas refund. The refund had already been removed by EIP-3529; deletion eligibility and refund eligibility are separate questions.
The proposal’s compatibility discussion identifies a practical casualty: designs that use CREATE2 and repeated destruction to redeploy code at the same address. Such a design cannot rely on deleting a contract created in a previous transaction. Reviewing the deployment sequence, rather than trusting the opcode’s name, reveals whether that replacement path still exists.
