# Evolution of CREATE2 Wisp Contracts and SELFDESTRUCT Security Risks Analyzing how EIP-6780 and Pectra updates reshaped contract metamorphism and execution security. - **Source:** [Ethereum](https://brifing.si/source/7f75df88-bffd-4d0a-8106-2c49e80ecfcd) - **Published:** 2026-11-01 - **Topic:** [Software & Engineering](https://brifing.si/c/engineering) - **Original article:** - **On Brifing:** https://brifing.si/s/35cd8200-cdb2-435e-994f-dd7989309479 ## The Wisp Pattern Legacy The Wisp pattern involved creating, utilizing, and self-destructing a contract within a single transaction to reuse addresses. Eight years ago, developers questioned the security implications of this metamorphism. The primary concern was whether users could audit one version of code while a malicious actor deployed another at the same address. ## Tornado Cash Attack Impact The 2023 Tornado Cash governance attack demonstrated the practical dangers of address reuse and contract replacement. This incident highlighted that relying on Etherscan audits was insufficient for preventing bait and switch tactics. The attack forced the ecosystem to reconsider how smart contract code identity is verified during critical governance execution phases. ## EIP-6780 Protocol Constraints Implemented during the Dencun upgrade in March 2024, EIP-6780 significantly restricted the functionality of the SELFDESTRUCT opcode. The update limited the operation to contracts created within the same transaction. This change effectively neutralized the traditional Wisp pattern, preventing long-term address metamorphism that previously allowed for deceptive code swapping in production. ## Pectra and EIP-7702 The Pectra upgrade, scheduled for May 2025, introduces EIP-7702, which enables Externally Owned Accounts to delegate to contract code. This evolution shifts the focus from simple contract destruction to more complex account abstraction models. Security professionals must now evaluate how delegation impacts existing allowlist mechanisms and potential address-based trust assumptions. ## Current Execution Verification Developers are currently debating the most effective methods for verifying code identity at execution time. While EXTCODEHASH remains a standard tool for checking contract bytecode, the industry is exploring alternative verification patterns. These methods aim to ensure that the code executed matches the audited version, regardless of recent protocol-level opcode modifications. ## Governance Risk Assessment Same-transaction metamorphism remains a theoretical concern for governance protocols and allowlists. Although EIP-6780 mitigated the most egregious risks, the ability to execute code within a single transaction still requires rigorous scrutiny. Governance systems must implement robust checks to ensure that contract state transitions are transparent and immutable during the execution window. ## Protocol Level Security Shifts The transition from relying on manual Etherscan audits to protocol-enforced opcode limitations marks a maturation in Ethereum security. By restricting SELFDESTRUCT, the network has moved toward a more predictable execution environment. This shift forces developers to adopt safer architectural patterns that do not rely on the temporary existence of contract code. ## Future of Contract Identity As the ecosystem moves toward Pectra, the definition of contract identity continues to evolve. The focus is shifting from preventing destruction to managing delegated execution. Professionals should monitor how these protocol changes affect smart contract security audits and ensure that their systems remain resilient against emerging patterns of code-based account delegation. ## Sources covering this story - https://www.reddit.com/r/ethereum/comments/1xl5h2q/8_years_ago_a_create2_wisp_post_asked_what_stops/ — --- _Summary written by Brifing from the original reporting. Copyright in the original article belongs to its publisher; read the full piece at the link above._