Self-Destruct Mechanism

A primary risk is forced Ether reception. When a contract self-destructs, it sends its Ether to a target address via a low-level .transfer() that bypasses the recipient's receive() or fallback() function. This can break assumptions in contracts that track balances via address(this).balance or rely on logic in their receive function. For example, a contract using checks like require(msg.value > 0) could still receive Ether it cannot account for, potentially leading to locked funds or incorrect state.

Using selfdestruct within a delegatecall context is exceptionally dangerous. delegatecall executes code in the context of the calling contract. If the called library or logic contract contains a selfdestruct opcode, it will destroy the caller contract, not the library. This has been a critical vulnerability in past exploits, where an attacker could trick a contract into executing a delegatecall to malicious code that triggers self-destruction.

selfdestruct poses a severe threat to upgradeable proxy patterns. If a proxy's logic contract (implementation) can be self-destructed, the proxy becomes permanently bricked, as all delegatecalls will fail, freezing all user funds. Secure upgrade patterns like Transparent or UUPS Proxies must ensure the implementation contract has no selfdestruct capability or that its activation is strictly permissioned to a trusted admin.

It's crucial to understand that selfdestruct does not erase the contract's historical data or code from the blockchain. Past transactions remain immutable. The operation:

• Sets the contract's Ether balance to zero.
• Renders the contract address unable to receive new transactions (calls revert).
• The bytecode at the address is not removed but becomes inert. Any Ether sent to the address after destruction is permanently lost.

Due to its complex risks and impact on state size, SELFDESTRUCT semantics are changing. EIP-4758 proposes to deprecate the opcode, replacing it with a SENDALL function that sends all Ether without deleting code. In the Shanghai upgrade, its behavior was altered to not refund gas. Developers must avoid relying on selfdestruct for new designs, as its future behavior is non-guaranteed and it may be fully removed in a subsequent hard fork.

If usage is unavoidable, follow strict patterns:

• Access Control: Restrict the function to a trusted owner or multi-sig.
• State Sanitization: Clear critical storage variables before destruction to prevent data leakage assumptions.
• Avoid in Libraries: Never include selfdestruct in delegatecall-able library code.
• Recipient Validation: Ensure the target address is an Externally Owned Account (EOA) or a contract explicitly designed to handle forced Ether. Consider using it only for end-of-life contract termination, not as a regular feature.

In Ethereum and EVM-compatible chains, SELFDESTRUCT is an opcode (0xff) that:

• Irreversibly deletes the contract's bytecode from the state.
• Forwards all remaining ether to a designated beneficiary address.
• Clears the contract's storage in most client implementations.
• Cannot be called after deletion, making the contract address unusable for new deployments.

Key Limitation: Since the EIP-6780 proposal, its functionality is restricted post-Cancun upgrade, primarily allowing self-destruction only within the same transaction it was created.

The Ethereum Merge and subsequent upgrades significantly altered SELFDESTRUCT's behavior and security model.

• EIP-3651 (Shanghai): Changed gas refund semantics, removing the large gas refund for using SELFDESTRUCT.
• EIP-6780 (Cancun): Drastically restricted the opcode. It now only works if the contract was created in the same transaction. This neuters its use in complex state-clearing attacks while preserving its original use case for singleton factory patterns.

This evolution highlights Ethereum's shift towards state minimization and reducing attack vectors for reentrancy and gas-related exploits.

Non-EVM and Layer 2 blockchains often implement different paradigms for contract lifecycle management.

• Solana: Programs are stateless; account storage is separate and paid via rent. Closing an account and reclaiming rent is analogous but not a direct SELFDESTRUCT.
• Avalanche C-Chain (EVM): Mirrors Ethereum's pre-EIP-6780 behavior but may adopt future changes.
• zkSync Era & Arbitrum: As EVM-compatible L2s, they implement the opcode but its effects are finalized on L1, following Ethereum's evolving rules.
• Cosmos (CosmWasm): Smart contracts can be migrated or instantiated with new code, but there is no direct bytecode deletion opcode.

Despite its hazards, SELFDESTRUCT enabled specific, legitimate patterns:

• Singleton Factories: Create2 factories that self-destruct after deploying a contract, ensuring a one-time use address.
• Contract Upgrades: In early upgrade patterns (now deprecated), a proxy would delegatecall to a logic contract that could be "destroyed" and replaced.
• Emergency Shutdown: Allowing a contract owner to permanently disable a contract and withdraw funds in case of a critical bug.
• Gas Optimization: Historically used to claim large gas refunds (24,000 gas), a practice eliminated post-EIP-3529.

The opcode introduced significant security complexities, leading to its restriction.

• Forced Ether Send: Could break logic in contracts that assumed address(this).balance only increased, causing denial-of-service.
• Storage Collision Attacks: In complex delegatecall proxy systems, destroying a logic contract could corrupt storage of proxies still pointing to it.
• Gas Griefing: Pre-refund removal, attackers could use it to manipulate block gas limits.
• Code Size Verification Bypass: Contracts checking extcodesize on another address could be fooled if that address self-destructed in the same transaction.

With SELFDESTRUCT restricted, modern development uses safer patterns.

• Pausable Contracts: Implement an emergency pause() function that blocks critical operations without destroying state.
• Upgradeable Proxies: Use UUPS or Transparent Proxy patterns with a dedicated upgradeTo function to change logic.
• Withdrawal Patterns: For shutdowns, implement a function that sweeps funds to an owner and sets a stopped boolean flag.
• CREATE2 for Deterministic Addresses: Use CREATE2 with a salt for predictable addresses without needing self-destruction.

The trend is towards explicit, reversible control mechanisms over irreversible destruction.

The SELFDESTRUCT (formerly SUICIDE) is an Ethereum Virtual Machine (EVM) opcode that permanently deletes a smart contract from the blockchain state. When executed, it:

• Transfers the contract's entire remaining Ether balance to a designated address.
• Clears the contract's code and storage from the state, freeing up storage gas refunds.
• Renders all future calls to the contract's address invalid (they will not execute code).

A key incentive for using selfdestruct was the gas refund mechanism. The EVM granted a refund of 24,000 gas for clearing a contract's storage, partially offsetting the cost of the transaction. This interacted with the gas limit and could enable complex transaction patterns. However, the EIP-3529 upgrade in the London hardfork significantly reduced these refunds to mitigate gas price manipulation attacks.

The selfdestruct mechanism has a unique interaction with CREATE2. A contract's address computed via CREATE2 depends only on the deployer's address and a salt, not the contract's code. Crucially, if a contract at a CREATE2 address calls selfdestruct, the same address can later be reused to deploy different contract code. This enables state channel patterns and upgradeable contract skeletons, but introduces security considerations for address assumptions.

In upgradeable proxy patterns, a proxy contract delegates calls to a logic contract. Using selfdestruct in the logic contract is extremely dangerous. If the logic contract self-destructs, the proxy's delegatecall will have no code to execute, permanently bricking the proxy and locking all associated funds and state. Modern upgradeability designs like Transparent Proxies or UUPS explicitly avoid or guard against this catastrophic failure mode.

Due to its complex side-effects and risks, selfdestruct is slated for deprecation. EIP-4758 proposes to deactivate the opcode in a future hardfork. The rationale includes:

• Simplifying Ethereum's state management and protocol complexity.
• Eliminating edge cases in account abstraction and Verkle tries.
• Removing the risk of funds being forcibly sent to non-existent or rejecting addresses. Post-deprecation, contracts will need alternative patterns for closing out funds.

Selfdestruct can forcibly send Ether to any address, bypassing receive functions or payable checks. This breaks a fundamental assumption of Ethereum: that contracts can reject Ether. Key risks include:

• Breaking invariants: A contract's logic may assume its balance only increases via specific functions.
• Denial-of-Service (DoS): Sending dust to a contract relying on address(this).balance for calculations.
• Locking funds: Forcing Ether into a non-payable or defunct contract can render it unrecoverable.