Severity depends on reachable impact and deployment context. Listed tools are review aids; their applicability depends on language, version and configuration.
Forced Ether sending breaks the assumption that every wei in a contract arrived through its payable functions. A contract may reject ordinary transfers and still receive Ether without executing its receive or fallback logic. The vulnerability is the balance-dependent assumption, not the unexpected transfer itself.
The Solidity security guidance identifies two ways Ether can arrive without a message call: directing a block reward to the address and using SELFDESTRUCT. Ether can also be sent to a deterministically computed contract address before that contract is deployed.
The Cancun change did not remove the transfer behavior. EIP-6780 specifies that SELFDESTRUCT still sends the contract's entire Ether balance to its target, while normally preserving the sender's code and storage. When executed in the same transaction as creation, it retains the older deletion behavior.
Exact-balance logic is the usual target. A lottery that advances only when address(this).balance equals recorded deposits can be blocked by one forced wei. A payout that treats every wei above recorded liabilities as revenue may instead give unsolicited funds to the wrong party. The sender usually cannot recover the forced Ether, so exploitation must justify that cost.
Find every read of the contract's Ether balance. Classify whether it checks solvency, derives user credit, gates a state transition, sets a price, or calculates an amount to transfer. Compare that use with explicit accounting for deposits, liabilities, fees, and reserves.
Test with zero, one wei, and larger unexpected balances before each important transition. Inject Ether before deployment when CREATE2 or predictable addresses are used. Verify deposits, withdrawals, finalization, refunds, and emergency recovery when actual balance exceeds accounted balance.
An invariant such as actual balance being at least recorded Ether liabilities can express solvency. Equality is usually too strong because surplus can arrive externally. Greater-than-or-equal is not a complete fix when logic distributes or prices that surplus.
Track obligations and protocol-owned revenue in state, updating them only through defined operations. Base claims and transitions on those records rather than the raw balance. Treat any positive difference as unsolicited surplus under an explicit policy.
Do not rely on an absent or reverting receive function to prevent forced Ether. Adding a receive function does not intercept SELFDESTRUCT transfers either. If governance can sweep surplus, specify who may sweep, which amount is truly unencumbered, and what happens during insolvency or pending withdrawals.
Avoid equality checks against the live balance for progress. If a solvency check is required, compare the balance against independently tracked liabilities and keep distribution calculations independent of unexplained surplus.
Repository analysis can locate raw balance reads and exact comparisons. It cannot prove whether a balance is forced or legitimate, identify all prefunding before deployment, or validate the economic ownership of surplus without protocol specifications and chain history.
Did EIP-6780 eliminate forced Ether through SELFDESTRUCT?
No. It changed deletion semantics but retained transfer of the sender's Ether balance to the target.
Can a contract refund forced Ether to its sender?
Not reliably. The receiving contract is not told who caused a SELFDESTRUCT transfer. Surplus handling needs a separate policy.
Firepan
Run a free scan — results in minutes, no credit card required.
Run Free Scan →Understand the ERC-20 allowance overwrite race, its transaction-ordering conditions, and safer approval and spending designs.
Learn how adversarial gas consumption can block progress, waste sponsored gas, or break calls, plus practical review, testing, and mitigation guidance.
Learn when block timestamps are safe for coarse scheduling, when they create exploitable assumptions, and how to test timing boundaries across EVM networks.