In this track: Write and read Solidity
Receive and fallback functions
Special entry points handle certain calls outside ordinary named-function dispatch.
A reception desk can have one route for simple deliveries and another for requests that do not match a named service.
This example begins with count zero and a request to call increment(). No real contract is deployed.
Animated local teaching model. No wallet, RPC or live blockchain data. Some labels and hashes are abbreviated for readability.
Receive handles a specific case
A payable receive function can handle an empty-calldata native-value call under Solidity dispatch rules. Its availability does not mean every conceivable ETH receipt path executes the same code.
Fallback catches unmatched dispatch
A fallback function handles calls that do not match an ordinary function, subject to the language’s receive/fallback selection rules. It needs payable capability to accept applicable native-value calls.
Proxies often use fallback machinery
A proxy can forward unmatched calldata to another implementation. That can change the effective function behavior while preserving a stable proxy address.
Keep safety separate
Receiving or forwarding code can fail and can involve external-call risks. The toy below accepts value but provides no withdrawal path, so it is a dispatch example rather than a recommended place to send assets.
Read the example
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
contract LearningExample {
event Received(address sender, uint256 amount);
receive() external payable {
emit Received(msg.sender, msg.value);
}
fallback() external {
revert("Unknown function");
}
}Educational dispatch example only: it intentionally has no withdrawal function.
Does a receive function handle every unmatched nonempty-calldata call instead of fallback?
Receive and fallback have distinct dispatch conditions.
Original explanations by EtherTools. Examples are educational and source-linked; this site is independent of the Ethereum Foundation. Our approach.