2

A receive function allows a contract to accept eth via a send() or transfer(). As someone thought it was a good idea to have both a receive and a fallback function, I was curious what sort of scenario would be helped by having an additional fallback function? I can't think of one so I figure I am missing something.

3

The receive function is called if no other function is found and the transaction includes Ethers. The fallback function is called if no other function is found.

Assuming the transaction doesn't call any known function, the fallback function is useful to catch non-Ether transactions.

Here are a few example use cases:

  1. Someone trying to call a transfer function (thinking it's an ERC20 contract) on a non-token contract - you could for example revert the transaction stating "You called the wrong contract, this isn't ERC20 contract".

  2. A contract which simply needs to store addresses of those who are trying to interact with it for some reason, so the user can just send an empty transaction to the contract.

  3. In general catching people who try to call functions which don't exist (probably using the wrong contract).

Granted, I can't think of many reasonable use cases for this either.

You can read more about the details for example here: https://solidity.ethereum.org/2020/03/26/fallback-receive-split/

3
  • I like this answer! – goodvibration Sep 21 '20 at 14:46
  • So it's not for helping the contract do stuff, but rather, help developers debug? – Eric Falkenstein Sep 21 '20 at 17:00
  • I added some a bit far-fetched examples. In general, I don't see too much use for it either. But probably someone else would for some specific scenarios. – Lauri Peltonen Sep 21 '20 at 17:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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