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

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]]