ethertools.
Learn/Execution traces and low-level calls
In this track: Execution traces and low-level calls
advanced · 4 MIN READ

SELFDESTRUCT after protocol changes

Historical deletion assumptions do not describe every modern case.

LET’S PICTURE IT

A command with an old name can retain only part of its earlier behavior.

SEE IT FOR YOURSELF
A valid counter call, step by stepStep 1 / 4
A valid counter call, step by stepFunction requestincrement()No argumentsBefore executionstored count0A local teaching example with a defined starting stateIncoming callCheck function dispatchCheck coded conditionsRules passConditions passContinue executionA failed check can revert insteadCalculation0 + 1Result: 1Storage writecount = 1Persists if call succeedsCalculating a local value and storing it are separate stepsPersistent statecount1Later readGetter reports 1No new incrementState, logs and browser display have different roles

This example begins with count zero and a request to call increment(). No real contract is deployed.

Animated local teaching model. No wallet, RPC or live blockchain data. Some labels and hashes are abbreviated for readability.

Specify the active rules

Under EIP-6780 behavior, the usual case outside the creation transaction does not delete code, storage or the account. Historical explanations must identify their fork assumptions.

Separate balance movement

The opcode can still transfer the account balance to its designated target and halt the frame. Balance effects and account deletion are different questions.

Recognize the narrow exception

Creation and self-destruction within the same transaction retain special behavior under that EIP. Do not generalize this exception into an unrestricted later deletion mechanism.

Avoid using old lifecycle patterns

A design relying on deleting and recreating arbitrary deployed code needs fresh analysis under the intended chain rules. Check current specifications and test the exact deployment context.

Follow the execution

Earlier transaction: contract created
Later transaction: SELFDESTRUCT
Under EIP-6780 usual case:
  balance transfer behavior remains
  code and storage are not deleted

A local conceptual trace with explicit assumptions; this is not a trace of a live transaction.

QUICK CHECK · NO PRESSURE

Under EIP-6780, does a later-transaction SELFDESTRUCT normally erase existing code?

Your progress stays in this browser.
Keep exploring the original referenceEthereum Improvement Proposals ↗

Original explanations by EtherTools. Examples are educational and source-linked; this site is independent of the Ethereum Foundation. Our approach.