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.
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 24.95M 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.
The behaviour of SELFDESTRUCT is changed in the following way:
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.
During transaction finalization, all accounts marked for selfdestruction, instead of being deleted, are modified as follows:
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.
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.
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 usage pattern remains operational.
For contracts not created in the same transaction in which SELFDESTRUCT is executed, the behavior is unchanged from EIP-6780.
Differently to Mainnet, the Optimizm-based L2 chains use the burn feature of the SELFDESTRUCT regularly. These systems require different addoption path.
TBD
SELFDESTRUCT behavior modification has combinatory effect on vast amount 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 addapted to the new behavior.Copyright and related rights waived via CC0.