--- eip: 8246 title: Remove SELFDESTRUCT Burn description: Eliminate the remaining cases where SELFDESTRUCT burns ETH. author: Paweł Bylica (@chfast) discussions-to: https://ethereum-magicians.org/t/eip-8246-remove-selfdestruct-burn/28416 status: Draft type: Standards Track category: Core created: 2026-05-01 requires: 161, 6780 --- ## 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](./eip-6780.md), 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](./eip-161.md). ## 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](./eip-6780.md). Unlike Mainnet, Optimism-based L2 chains use the burn feature of `SELFDESTRUCT` regularly. These chains will require a separate migration plan. ## Test Cases ### Unmodified behavior General test coverage of the `SELFDESTRUCT` instruction is expected to be excellent already because this instruction has been modified multiple times in the past. Updating existing test cases to align with this EIP should give us good coverage of all **unmodified** features of `SELFDESTRUCT`. ### Modified behavior Each of the following test cases should be executed (where physically meaningful) across the combinations of these factors: - level: top-level transaction, internal call, - call type: CALL (including top-level tx), CREATE (including top-level tx), CREATE2, - code state: SELFDESTRUCT executed inside initcode (before deployment) / from deployed code, - status: SELFDESTRUCT succeeds, SELFDESTRUCT fails due to OOG, - revert: effects of SELFDESTRUCT are committed to the post-state, effects of SELFDESTRUCT are reverted (only for wrapped internal calls), - balance: balance of the selfdestructing account at the SELFDESTRUCT instruction is zero / non-zero. #### Instruction level 1. Same-transaction selfdestruct-to-self. 2. Same-transaction selfdestruct-to-self, followed by selfdestruct-to-self. 3. Same-transaction selfdestruct-to-self, followed by selfdestruct-to-other. 4. Same-transaction selfdestruct-to-other, followed by selfdestruct-to-self. #### Transaction finalization 5. Same-transaction selfdestruct-to-other, followed by a CALL with value to the selfdestructed account. 6. Same-transaction selfdestruct-to-other, followed by multiple CALLs with value to the selfdestructed account. 7. Same-transaction selfdestruct-to-other, followed by a CALL with value to the selfdestructed account, followed by selfdestruct-to-other. 8. Same-transaction selfdestruct-to-other, followed by a CALL with value to the selfdestructed account, followed by selfdestruct-to-self. 9. Same-transaction selfdestruct-to-self, followed by a CALL with value to the selfdestructed account. 10. Same-transaction selfdestruct-to-self, followed by multiple CALLs with value to the selfdestructed account. 11. Same-transaction selfdestruct-to-self, followed by a CALL with value to the selfdestructed account, followed by selfdestruct-to-other. 12. Same-transaction selfdestruct-to-self, followed by a CALL with value to the selfdestructed account, followed by selfdestruct-to-self. 13. Create new account, new account creates other accounts to bump its nonce, new account selfdestruct-to-self. 14. Create new account, new account creates other accounts to bump its nonce, new account selfdestruct-to-other. 15. Create new account, new account adds new storage, new account selfdestruct-to-self. 16. Create new account, new account adds new storage, new account selfdestruct-to-other. #### Multi-transaction 17. Tx-1: CREATE2 new account with non-zero balance, new account selfdestruct-to-self. Tx-2: Repeats Tx-1. ## 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](../LICENSE.md).