---
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 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.

## Specification

The behaviour of `SELFDESTRUCT` is changed in the following way:

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.

3. Note: all other behavior of `SELFDESTRUCT` is unchanged.
4. 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 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).

Differently to Mainnet, the Optimizm-based L2 chains use the burn feature of the `SELFDESTRUCT` regularly. These systems require different addoption path.

## Test Cases

TBD

## Security Considerations

1. `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.
2. In case of usage expecting the ETH burn to happen the transaction will create dust-like accounts with potentially locked non-zero balance. However, the new account creation cost is properly included in the transaction cost. Only 2 such events have been recorded on Mainnet (Cancun–25M) so far.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).
