SELFDESTRUCT ABUSE: CURRENT EVM BEHAVIOR AND REVIEW

SELFDESTRUCT is deprecated, but it has not become a no-op. On Ethereum after EIP-6780, calling it from a contract that existed before the current transaction halts that frame and transfers the contract's full Ether balance to the beneficiary without deleting its code or storage. If the contract was created earlier in the same transaction, the historical deletion behavior remains. Other EVM networks may activate different fork rules, so reviewers must verify the target chain.

WHERE THE RISK REMAINS

Forced Ether is the broadest current risk. A contract can receive Ether through SELFDESTRUCT without executing its receive or fallback function. Solidity's security guidance also notes block rewards as another path that does not make a normal message call. Logic that assumes address(this).balance equals accounted deposits can therefore be blocked or mispriced by an unsolicited balance.

EIP-6780 also breaks older designs that expected an established contract to delete itself and later be redeployed at the same CREATE2 address. Its code and storage now remain. Conversely, a constructor can still invoke SELFDESTRUCT in the creation transaction, so factories and counterfactual-address designs must reason about that narrow exception.

The vulnerable condition is an assumption, not merely the presence of the opcode. Examples include exact balance equality controlling progress, authorization based on an address being code-free after destruction, and upgrade schemes that require cross-transaction delete-and-redeploy behavior.

REVIEW AND TESTING

Search both Solidity and assembly for selfdestruct, then classify each call by when the executing contract was created and which chain rules apply. Independently search for address(this).balance, especially equality checks and calculations that treat the balance as protocol accounting.

Tests should force one wei and a larger amount into the target without calling it, then rerun settlement, withdrawal, and invariant checks. For factory designs, test create-and-destroy in one transaction separately from destroying a previously deployed instance. Fork tests must pin a block and chain whose EIP-6780 status is known.

Firepan can inspect a submitted repository and commit for SELFDESTRUCT, CREATE2, and balance-dependent logic in that scope. It does not monitor every deployment or determine unprovided chain configuration automatically.

MITIGATION AND LIMITS

• Keep liabilities, deposits, and claimable amounts in explicit storage; do not derive them from the raw Ether balance.
• Avoid exact balance equality as a liveness condition. Changing == to >= is only safe after reviewing what excess Ether does to every calculation.
• Do not use SELFDESTRUCT as an upgrade or lifecycle mechanism. Use a reviewed proxy or migration design where upgradeability is required.
• Treat unsolicited Ether as possible even when receive and fallback revert.

A permissive receive function does not capture forced transfers because it is not called. A sweep function can recover surplus, but it needs explicit authorization and accounting rules so it cannot take funds owed to users.

SOURCES

• EIP-6780: SELFDESTRUCT Only in Same Transaction
• EIP-6049: Deprecate SELFDESTRUCT
• Solidity Documentation: Sending and Receiving Ether