In the recommendations for smart contract security I read the following:

" Remember that Ether can be forcibly sent to an account Beware of coding an invariant that strictly checks the balance of a contract.

An attacker can forcibly send wei to any account and this cannot be prevented (not even with a fallback function that does a revert()).

The attacker can do this by creating a contract, funding it with 1 wei, and invoking selfdestruct(victimAddress). No code is invoked in victimAddress, so it cannot be prevented. "

Does that mean that the fallback function can't do a revert() or does that mean that the fallback function is not invoked if ether is sent to a contract in that manner?

2 Answers 2


The fallback payable function is not invoked in the following three scenarios:

1) Ether is sent in a selfdesctruct

2) Ether is sent from mining by setting the contract as the target for rewards

3) Ether is sent to the address before the contract exists in that address.

So, in essence, you can't prevent Ether being sent to the contract in these three cases.

You can read more about it for example here: https://medium.com/@alexsherbuck/two-ways-to-force-ether-into-a-contract-1543c1311c56


That is correct. If ether is sent to a contract via the selfdestruct of another contract, the receiving contract does not have any way to prevent it. No code, including the fallback function, is executed.

In fact, this can even be used to send ether to a function with no payable functions at all.

This also applies if ether is mined directly to the contract address, or by sending it via a regular transaction to the address before the contract is deployed (a contract's address can be predicted if you know the address which will perform the deployment transaction).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.