/selfdestruct-eip6780

name: selfdestruct-eip6780
description: Detect selfdestruct misuse and EIP-6780 implications post-Cancun — bricked contracts, broken `assert(balance == X)` invariants, factory patterns relying on redeploy, deployment-tx-only selfdestruct corner cases. Activate on `selfdestruct`, `suicide`, `CREATE2` factories, contracts asserting on `address(this).balance`.

selfdestruct / EIP-6780 detection

EIP-6780 background

After Cancun (March 2024), `selfdestruct` no longer deletes the contract's code or storage *unless* called in the same transaction as the contract's deployment. It does still transfer all ether to the recipient. This changes the security model substantially:

• Pre-6780: any `selfdestruct` could brick a contract → many DoS attacks.
• Post-6780: `selfdestruct` outside the deploy-tx only forwards ether. Code/storage survives.

When this applies

• Any `selfdestruct` call
• Contracts that assert `address(this).balance == X` (someone can force-add ether via `selfdestruct`)
• `CREATE2` factories relying on redeploy at same address (now broken — code persists)
• Diamonds / proxies with implementation-side selfdestruct
• Pre-Cancun deployed contracts (legacy semantics still apply at runtime)

Detection patterns

Forced-ether DoS on balance-equality assumption (HIGH — still relevant)

require(address(this).balance == expected);   // ← attacker can `selfdestruct` ether to break this

Track expected balance in a state variable, not via `address(this).balance`.

CREATE2 redeploy pattern broken (HIGH)

// Pattern: deploy logic to deterministic addr, selfdestruct to "upgrade", redeploy.
// ← Post-6780, code persists. Redeploy at same address fails or reverts.

Migrate to true proxy patterns.

selfdestruct in deploy-tx (still has full power) (HIGH)

A constructor that selfdestructs in the deploy tx truly deletes code+storage. Some "metamorphic" tricks abuse this.

Library / facet with selfdestruct path reachable (HIGH)

Pre-6780-deployed diamond facets with selfdestruct paths remain dangerous. Even post-6780, a facet selfdestruct that orphans ether still costs.

selfdestruct sending ether to known-revert recipient (LOW)

Selfdestruct still forwards ether — recipient cannot revert on receive (selfdestruct bypasses fallback). So this isn't a DoS for the destructor, but can leave the recipient with unexpected balance.

Recovery via selfdestruct on stuck-fund contract (LOW-MEDIUM)

Sometimes a useful pattern — note intent.

Severity rubric

| Pattern | Severity | |---|---| | `address(this).balance == X` invariant | **High** | | Public `selfdestruct` path on deployed contract | **High** | | CREATE2 redeploy/upgrade pattern (post-Cancun broken) | **High** | | Diamond facet selfdestruct reachable | **High** | | Constructor metamorphic selfdestruct | **High** *(may be intentional, document)* | | `selfdestruct` to known revert-on-receive recipient | **Low** | | `selfdestruct` as legitimate recovery, properly guarded | **Info** |

Remediation patterns

• Don't use `address(this).balance` as part of any invariant. Track received ether explicitly.
• Migrate metamorphic / CREATE2-redeploy patterns to standard proxies (UUPS / Transparent).
• Remove `selfdestruct` from production contracts unless absolutely needed.
• If retained, guard heavily (multi-sig + timelock).

False-positive notes

• A contract using `selfdestruct` only in a test-helper or migration script → not deployable, ignore.
• `selfdestruct` whose recipient is the contract's own address — does nothing useful, comment as code smell.

Related

• [[delegatecall-risks]]
• [[dos-vectors]]
• [[access-control]]