Open this lesson in your favourite AI. It'll walk you through the why, explain the demo, and quiz you on the try-it list.
Before Cancun, SELFDESTRUCT both removed the contract's code and forwarded its balance. After EIP-6780, the code-removal behavior only triggers if SELFDESTRUCT is called in the same transaction as the contract's creation — making it nearly useless for runtime cleanup but preserving the metamorphic-contract attack vector for security review. This is one of the most consequential semantics changes in recent EVM history.
Two scenarios — one where SELFDESTRUCT removes code, one where it doesn't.
eth_getCode still returns the bytecode.eth_getCode returns 0x.Use these three in order. Each builds on the one before.
In one paragraph, explain what SELFDESTRUCT used to do pre-Cancun and what changed in EIP-6780.
Walk me through the EVM-level decision in EIP-6780 — what state determines whether code removal happens.
Given a protocol that uses CREATE2 + SELFDESTRUCT for metamorphic upgrades, explain how that pattern still works post-Cancun and what the security implications are for users who hold tokens issued by the contract.
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
contract SelfDestructible {
function destroy(address payable to) external {
selfdestruct(to);
}
}
// Scenario A: deployed in tx1, destroyed in tx2 — POST-CANCUN behavior:
// - Balance is still forwarded to `to