Remove SELFDESTRUCT Burn

Abstract

This EIP removes the remaining cases where SELFDESTRUCT burns ETH. Accounts marked for selfdestruction still have their code, storage, and nonce cleared at transaction finalization, but any remaining balance is preserved.

Motivation

The remaining burn behavior of SELFDESTRUCT is almost completely unused, but it still forces special-case handling in EVM implementations, specifications, and tests.

After EIP-6780, ETH can still be burned only when a contract created in the same transaction executes SELFDESTRUCT, either with itself as beneficiary or in a case where the contract receives additional ETH (via CALL or via SELFDESTRUCT, potentially multiple times) later in the same transaction. A full replay of Ethereum mainnet from genesis to approximately block 25M found only 2 post-Cancun burns through this path and 0 cases of balance being burned during transaction finalization. By comparison, pre-Cancun history contained 54 self-burns in total. This indicates that the remaining burn behavior is rarer than the burn behavior already removed by EIP-6780, so the complete removal proposed here should affect fewer transactions than the partial removal already introduced there.

Removing the final burn cases simplifies SELFDESTRUCT semantics and avoids preserving an exotic special case that is barely used in practice.

As a consequence, this also removes the last EVM mechanism by which ETH can leave total supply.

Specification

The behavior of SELFDESTRUCT changes as follows:

1. When SELFDESTRUCT is executed in the same transaction as the contract was created, and if the beneficiary address is the executing account address, the balance of this account remains unchanged.

2. During transaction finalization, all accounts marked for selfdestruction, instead of being deleted, are modified as follows:

   1. nonce is reset to 0,
   2. balance is unchanged,
   3. code is cleared,
   4. all storage is cleared.

Note: All other behavior of SELFDESTRUCT is unchanged.

Note: If the resulting balance is 0, the account is empty and is deleted from the state by EIP-161.

Rationale

This change removes burn behavior at its source instead of adding dedicated handling for it elsewhere.

The chosen design preserves the state-clearing effect of SELFDESTRUCT for contracts created in the same transaction. The account may still survive in the state, but only as a balance-only account. This removes the special case where ETH disappears from the state while keeping the account non-executable after transaction finalization.

Resetting the nonce to 0 ensures that a future CREATE2 at the same address is not blocked by a preserved balance-only account.

An alternative would be to preserve the whole account, including nonce, code, and storage. That would work as a complete SELFDESTRUCT disarming and would remove the burn as well, but it would be a larger semantic change than necessary. This EIP removes only the burn behavior.

Backwards Compatibility

This EIP requires a hard fork, since it modifies consensus rules.

Previously it was possible to burn ETH by executing SELFDESTRUCT in a contract created in the same transaction, either by targeting the executing contract as beneficiary or by sending ETH to the contract after SELFDESTRUCT and before transaction finalization. After this EIP, ETH will not be burned in either case.

Previously such contracts were always deleted at transaction finalization. After this EIP, a contract with zero final balance is still deleted, but a contract with nonzero final balance remains in the state as a balance-only account with empty code, empty storage, and nonce 0.

For the balance-only accounts created this way, CREATE2 still may recreate a contract at the same address in a follow-up transaction. Such a usage pattern remains operational.

For contracts not created in the same transaction in which SELFDESTRUCT is executed, the behavior is unchanged from EIP-6780.

Unlike Mainnet, Optimism-based L2 chains use the burn feature of SELFDESTRUCT regularly. These chains will require a separate migration plan.

Test Cases

TBD

Security Considerations

1. SELFDESTRUCT behavior modification has a combinatorial effect on a vast number of test scenarios involving multi-call/create contract interactions. This EIP requires significant testing effort. However, many existing test cases for EIP-6780 can be adapted to the new behavior.
2. When a use case relies on the ETH burn happening, the transaction will create dust-like accounts with potentially locked non-zero balance. However, the new account creation gas cost is paid by the transaction, so dust accounts are not a free DoS vector. Only 2 such events have been recorded on Mainnet (Cancun–25M) so far.

Copyright

Copyright and related rights waived via CC0.