Fallback function

I read a lot staff article and soliditylang documents but I dont understand why we use fallback function

for example, if I use receive function in all contracts I will not need to fallback function

could you tell me why we use?


1 Like

Hi @veridelisi,

Sorry for the late reply to your very good and interesting question!

From what I can determine, whether a contract needs a receive Ether function or a fallback function, or both, depends on what the outcome should be when the contract receives a call from an external contract (i) with or without an Ether value, and/or (ii) with or without a bytes calldata argument: which specific combinations, or variety of combinations, of these inputs should result in the successful execution of a default function; what operations does a default function need to be able to perform; and which combinations, if any, of these inputs should cause the transaction to revert.

For example …

  1. If our contract contains a receive Ether function, but no fallback function, then it can receive Ether from an external contract call which uses the send or transfer methods, or which uses the call method with an empty bytes calldata argument.
    If the external contract call uses the call method to send Ether with bytes calldata, the transaction will revert, because a receive Ether function will not execute when the external contract call includes calldata.
    However a receive Ether function will still execute if the external contract call doesn’t send any Ether and the calldata argument is empty.

  2. If our contract contains both a receive Ether function and a payable fallback function, then the receive Ether function will execute if the external contract call sends Ether with an empty bytes calldata argument, because whenever a contract contains a receive Ether function, this will always take precedence over any payable fallback function which could also potentially be executed.
    The contract will still be able to receive the Ether if calldata is also sent, because in this case the payable fallback function will execute instead.
    If no Ether value is sent, then the receive Ether function will execute if the calldata argument is empty, but the payable fallback function will execute if only calldata is sent.

  3. A fallback function can either be defined as payable, or restricted to non-payable, whereas a receive Ether function must be payable. So, if we want a transaction to revert whenever an external contract call sends an Ether value to our contract by mistake, we would need our contract to have a non-payable fallback function only.

  4. As well as receiving bytes calldata as an input, a fallback function can also return this value as an output by including:
    –  a  bytes calldata  parameter;
    –  a  return msg.data;  statement; and
    –  returns(bytes memory)  in the function header.

In the following linked article, the flow diagram at the top of the second file of example code is a nice illustration of how different circumstances can lead to different outcomes in terms of whether a receive Ether function or a fallback function is executed:


And here is a link to the relevant section in the Solidity documentation about the receive Ether and fallback functions. It’s quite technical, and the example code is quite dense, but it does give you a good idea of where to start experimenting with these functions yourself, which I would suggest is the best way to start to get a real idea of what the differences are from a practical point of view.


I hope that gives you a better idea, or at least starts to give you a feel for what the differences are between these two special functions. Let me know if you have any further questions :slight_smile:


Thank you jon
this is great

1 Like