In the world of smart contracts, unexpected situations can arise. A user might attempt to call a function that doesn’t exist, or Ether might be sent directly to the contract without specifying a function. To handle these scenarios gracefully, Solidity provides a special function called the fallback function. This function is the safety net of smart contracts. It provides a way to handle unexpected messages and to ensure that the contract remains in a valid state. It’s executed when a contract receives a message not handled by its other functions.

A fallback function can be virtual, overridden, and modified. Whenever a call to the contract is made, the fallback function is run if none of the other functions match the specified function signature or if no data was sent and there’s no receive Ether function. The fallback function always gets data, but it must also be marked payable to receive Ether.

Characteristics of the fallback functions

  • No parameters or return values: The fallback functions accept no parameters and return no values. They’re primarily intended to handle incoming calls and Ether transactions.

  • External and payable: The external payable functions must be declared. The external visibility modification enables the function to be invoked from outside the contract, and the payable modifier indicates that it can receive Ether.

  • Visibility: The fallback functions must be externally accessible and callable outside the contract.

  • Override, virtual, and modifiable: The fallback functions, like regular functions, can be designated as virtual, override, and modifiable. This enables contract design flexibility and customization in derived contracts.

  • Gas limitation: The fallback functions can accomplish intricate operations, but they have finite limits, particularly if they’re specified as payable. In the worst-case scenario, they can only rely on 2300 gas, limiting the intricacy of procedures that can be carried out.

Use cases of the fallback functions

The following are frequent uses of the fallback functions:

  • Custom Ether handling: They manage Ether transfers and balances within the contract, such as tracking user deposits or implementing custom payment logic.

  • Error handling: They provide a way for gracefully handling unexpected or invalid calls, such as denying Ether transfers with particular circumstances.

  • Fallback for unknown calls: They serve as a catch-all for calls that don’t match any specific function signature in the contract.

  • Interface compatibility: They ensure compatibility with interfaces that require a fallback function, such as ERC-223 or older versions of ERC-20 tokens.

Parameterized and non-parameterized

There are two types of fallback functions:

  • Non-parameterized fallback: This function is declared as fallback() external payable and can receive Ether but not data. It’s called when a call to the contract returns no results.

  • Parameterized fallback: This version receives the whole data supplied to the contract (equivalent to msg.data) and is declared as fallback (bytes calldata input) external payable returns (bytes memory output). It can return data without ABI encoding, providing users with greater data processing options.

Get hands-on with 1200+ tech skills courses.