This page is a placeholder. All examples on this page are currently AI-generated and are not correct. This documentation will be completed in the future with accurate, tested examples.
Overview
Opcode: 0xff
Gas: 5,000 (warm) / 30,000 (cold)
Hardfork: Frontier
Stack Input: address (recipient of remaining balance)
Stack Output: (none)
Status: Being deprecated (EIP-6049)
SELFDESTRUCT transfers all remaining Ether to a target address and marks the contract for deletion at the end of the transaction.
Specification
Operation
- Pop recipient address from stack
- Transfer contract’s entire balance to recipient
- Mark contract for deletion
- Halt execution (like STOP)
- Contract code removed at end of transaction (post-EIP-6780: only in same transaction as creation)
Deprecation Status (EIP-6049)
SELFDESTRUCT is being deprecated due to security and complexity issues:
EIP-6780 (Cancun) - Behavior Change
Post-Cancun, SELFDESTRUCT only deletes code if called in same transaction as CREATE/CREATE2:
Future (EIP-4758) - Full Removal
Planned removal in future hardfork. Use alternatives:
- Send balance with CALL
- Disable contract with storage flags
- Upgrade via proxy pattern
Gas Cost
Range: 5,000 - 55,000 gas
Examples
Basic Self-Destruct
Assembly
Factory Pattern (Works in Cancun)
Behavior Changes Across Hardforks
| Hardfork | Change |
|---|
| Frontier | Introduced - deletes code, refunds 24,000 gas |
| Tangerine Whistle (EIP-150) | Gas cost: 0 → 5,000 |
| Spurious Dragon (EIP-161) | Don’t create empty accounts |
| Berlin (EIP-2929) | +25,000 gas for cold access |
| London (EIP-3529) | Removed 24,000 gas refund |
| Cancun (EIP-6780) | Only deletes code in same transaction as creation |
| Future (EIP-4758) | Full removal planned |
Edge Cases
Balance Transfer
Multiple Calls in Same Transaction (Pre-Cancun)
Receiving Contract Rejection
If recipient is contract with failing receive/fallback:
Security
Funds Recovery
Problem: Users send ETH to contract after destruction
Pre-Cancun:
Post-Cancun (EIP-6780): Code remains if destroyed in different transaction, funds not lost.
Attack: Deploy malicious contract, destroy, redeploy different code at same address
Mitigation: EIP-6780 prevents code deletion after creation transaction, making this impossible.
Reentrancy via Forced ETH Send
Mitigation: Checks-effects-interactions pattern.
Alternatives (Recommended)
1. Transfer Balance via CALL
2. Proxy Pattern
3. Circuit Breaker
Implementation
Testing
Benchmarks
| Scenario | Gas Cost |
|---|
| Warm recipient, exists | 5,000 |
| Cold recipient, exists | 30,000 |
| Cold recipient, new account | 55,000 |
References
- CREATE - Contract creation
- CREATE2 - Deterministic creation
- CALL - External calls (alternative for balance transfer)