Solidity 0.6.x Features: Fallback and Receive Functions
Exploring two key features of Solidity 0.6.x
In versions of Solidity before 0.6.x, developers typically used the fallback function to handle logic in two scenarios:
- A contract received ether and no data.
- A contract received data, but no function matched the function called.
The main use case of the pre-0.6.x fallback function was to receive Ether and react to it — a typical pattern used by token-style contracts to reject transfers, emit events, or forward the Ether. The function executes when a contract is called without any data (e.g. via .send() or .transfer() functions). The 0.5.x syntax is:
The second use case was made popular by the “delegate proxy” pattern for implementing upgradeable contracts. It has a simple proxy contract that only declares a fallback function. The fallback function is invoked when no function in the contract matches the function identifier in the call data. This permits the “delegate proxy” pattern where functionality is implemented outside the called contract. Here is an example of the implementation:
Calling the contract uses assembly code that we won’t go into here, but you can read more in Zeppelin’s documentation.
Splitting the Fallback Function
We realised that the dual purpose of the function confused developers, which could lead to potential security problems. For example, a developer typically implements a fallback function expecting only Ether transfers to call it, but it is also called when a function is missing from a contract. And confusingly, as this was expected behaviour, no error was reported. Here is an example of this confusing behaviour:
When calling CharitySplitter.donate() with a charity contract address, its processDonation function is correctly invoked to process the donation as expected. However, if by mistake the Receiver contract address is passed, its fallback function ends up being called, swallowing the sent value:
Since the EVM is untyped, Solidity is unable to check the actual type of a contract from its address and has to rely on what the user supplies. The function signatures also do not provide a perfect solution against type confusion but can work in many cases.
This is why the fallback function in version 0.6x was split into two separate functions:
receive() external payable— For empty call data (and any value)fallback() external payable— When no other function matches (not even thereceivefunction). Optionallypayable.
This separation provides an alternative to the fallback function for contracts that want to receive plain Ether.
receive()
A contract can now have only one receive function that is declared with the syntax receive() external payable {…} (without the function keyword).
It executes on calls to the contract with no data (calldata), such as calls made via send() or transfer().
The function cannot have arguments, cannot return anything, and must have external visibility and payable state mutability. To replicate the example above under 0.6.0, use the following code:
fallback()
The fallback function now has a different syntax that is declared using fallback() external [payable] {…} (without the function keyword). This function cannot have arguments, cannot return anything, and must have external visibility. The fallback function always receives data, but to also receive Ether, you should mark it as payable. To replicate the example above under 0.6.0, use the following code:
Migrated and Fixed Sample Contract
Thus, we translate the problematic contract to v0.6.x , having it declare a receive() function that only accepts incoming Ether without data and avoids the type confusion that led to the loss of value demonstrated above.
The calls to the fixed contract will now revert when calls with the Receiver contract address fail:
// The following call now reverts
await charitySplitter.donate(badCharity, { value: 10 });We hope you find the logical division of the fallback function clearer for your design and welcome any feedback you have on the new syntax.
