Ethereum EIP-8246 reaches its review deadline for remaining SELFDESTRUCT burns

A review deadline rather than network activation

EIP-8246, titled “Remove SELFDESTRUCT Burn,” reaches the November 4, 2026 last-call deadline listed in Ethereum’s official proposal registry. Created on May 1 by Paweł Bylica, the document still displayed Last Call status when we read it. Its goal is to remove the remaining cases in which the SELFDESTRUCT instruction makes ether disappear from a contract balance. This documentary milestone is not a deployment decision: the text says implementation would require a change to consensus rules and therefore a network upgrade.

The scope is narrow. Since EIP-6780, the relevant cases involve a contract created and subjected to SELFDESTRUCT within the same transaction. A balance can still be destroyed when the contract names itself as beneficiary, or receives more ether after the instruction but before transaction finalization. The author wants to remove these rarely used exceptions to simplify implementations, specifications, and tests of the Ethereum Virtual Machine.

The balance would survive the contract’s removal

The proposed change would preserve the balance when the beneficiary is the contract’s own address. At finalization, code and storage would be cleared and the nonce reset to zero, while remaining funds would be preserved. An account with no balance would still be deleted under existing rules. An account retaining funds could survive as a balance-only account without executable code. Other SELFDESTRUCT behavior would remain as described by EIP-6780.

Distinguishing the program from its value avoids confusing code removal with disappearing funds. However, it does not guarantee that the former user can freely recover the balance. The proposal specifically allows a contract to be recreated at the same address through CREATE2 in a later transaction. Developers therefore need to examine redeployment conditions rather than assuming an address that has lost its code is permanently unusable or controlled by only one person.

Some secondary networks would need separate changes

The document identifies a difference between Ethereum and certain secondary networks. In the OP Stack, the contract that passes messages to the main layer uses this burn mechanism to handle balances associated with withdrawals. Chains depending on that logic would need a separate migration plan if they adopted the modification. The change therefore cannot simply be applied to every Ethereum-compatible implementation without examining its system contracts and accounting.

The security section calls for substantial testing, especially interactions among calls, contract creation, and transaction reverts. It also notes that a permissionless factory could let another party recreate an address and take the preserved balance when CREATE2 conditions are met. The November 4 development is therefore a review deadline: subsequent status, tests, possible adaptations, and an activation schedule must be checked separately. The arrival of this date alone establishes no change to user balances.