Fallback Functions in Solidity

Solidity has two special functions that handle incoming transactions your contract did not explicitly plan for: receive() and fallback(). They look similar, but they serve different purposes. This post explains what each function does, how Solidity decides which one to call, and how to use them correctly.

How Solidity Routes Incoming Transactions

When a transaction arrives at your contract, Solidity runs through a decision tree before executing any code.

First, it checks whether msg.data is empty.

If msg.data is empty, Solidity looks for a receive() function. If one exists, it runs. If not, Solidity falls back to fallback().

If msg.data is not empty, Solidity skips receive() entirely and goes straight to fallback().

Here is that logic as a diagram:

         incoming transaction
                 |
        msg.data is empty?
           /           \
         yes             no
          |               |
  receive() exists?    fallback()
      /        \
    yes          no
     |            |
 receive()     fallback()

The separation is intentional. Plain Ether transfers have no data. Function calls and other interactions do. This lets you handle each case with different logic.

The Two Functions

receive()

receive() handles plain Ether transfers. When someone sends Ether to your contract without calling any function, this is what runs.

1contract ReceiveExample {
2    event Received(address sender, uint amount);
3
4    receive() external payable {
5        emit Received(msg.sender, msg.value);
6    }
7}

receive() must be external and payable. It takes no parameters and returns nothing.

fallback()

fallback() is the catch-all. It runs when someone calls a function that does not exist on your contract, or when Ether arrives with data but no receive() function is defined.

1contract FallbackExample {
2    event FallbackCalled(address sender, uint amount, bytes data);
3
4    fallback() external payable {
5        emit FallbackCalled(msg.sender, msg.value, msg.data);
6    }
7}

Like receive(), fallback() must be external. The payable modifier is optional. Without it, your fallback function will reject any Ether sent with the call.

A Complete Example

This contract implements both functions and logs which one was triggered:

 1contract TestContract {
 2    event Log(string func, address sender, uint value, bytes data);
 3
 4    fallback() external payable {
 5        emit Log("fallback", msg.sender, msg.value, msg.data);
 6    }
 7
 8    receive() external payable {
 9        emit Log("receive", msg.sender, msg.value, "");
10    }
11}

And here is a contract to test it:

 1contract Sender {
 2    function sendToReceive(address payable target) public payable {
 3        // Empty data, so receive() runs
 4        target.call{value: msg.value}("");
 5    }
 6
 7    function sendToFallback(address payable target) public payable {
 8        // Non-empty data, so fallback() runs
 9        target.call{value: msg.value}(abi.encodeWithSignature("nonExistentFunc()"));
10    }
11}

When sendToReceive runs, msg.data is empty, so receive() executes. When sendToFallback runs, msg.data contains the encoded function signature, so fallback() executes.

What Happens With Only One Function

Only fallback(), no receive()

If you define fallback() but not receive(), all incoming transactions route through fallback(). Plain Ether transfers and calls with data both end up there.

1contract OnlyFallback {
2    event Log(string message);
3
4    fallback() external payable {
5        emit Log("all transactions come here");
6    }
7}

This works, but you lose the ability to distinguish between plain transfers and unexpected function calls.

Only receive(), no fallback()

If you define receive() but not fallback(), calls to non-existent functions will revert. There is nothing to catch them.

1contract OnlyReceive {
2    event Log(string message);
3
4    receive() external payable {
5        emit Log("plain ether accepted");
6    }
7}

Plain Ether transfers work fine. Any call with data causes a revert.

A Real Wallet Example

Here is a pattern you will see in practice. The contract accepts plain Ether but explicitly rejects calls to functions that do not exist:

 1contract Wallet {
 2    event Deposit(address from, uint amount);
 3    event FallbackTriggered(address from, bytes data);
 4
 5    receive() external payable {
 6        emit Deposit(msg.sender, msg.value);
 7    }
 8
 9    fallback() external payable {
10        emit FallbackTriggered(msg.sender, msg.data);
11        revert("Function does not exist");
12    }
13}

Using revert in fallback() is a common defensive pattern. If someone accidentally sends a transaction with the wrong function signature, the call fails cleanly instead of silently doing nothing.

Testing Which Function Runs

This contract lets you verify the routing yourself:

 1contract FlowTest {
 2    uint public receiveCount;
 3    uint public fallbackCount;
 4
 5    receive() external payable {
 6        receiveCount++;
 7    }
 8
 9    fallback() external payable {
10        fallbackCount++;
11    }
12
13    function getBalance() public view returns (uint) {
14        return address(this).balance;
15    }
16}
17
18contract Tester {
19    function testReceive(address payable target) public payable {
20        (bool success,) = target.call{value: msg.value}("");
21        require(success);
22    }
23
24    function testFallback(address payable target) public payable {
25        (bool success,) = target.call{value: msg.value}(
26            abi.encodeWithSignature("random()")
27        );
28        require(success);
29    }
30}

Deploy FlowTest, then call testReceive and testFallback from Tester. Check receiveCount and fallbackCount to see exactly which function ran.

Key Rules

Both receive() and fallback() must be external. Using public will not compile:

1// Correct
2receive() external payable { }
3fallback() external payable { }
4
5// Will not compile
6receive() public payable { }

To accept Ether, the function must be payable. Without it, any Ether sent with the transaction causes a revert:

1// Accepts Ether
2receive() external payable { }
3
4// Rejects Ether
5receive() external { }

Neither function takes parameters or returns values. Attempting this will not compile:

1// Will not compile
2fallback(uint x) external payable { }
3fallback() external payable returns (uint) { }

If neither receive() nor fallback() is defined, your contract cannot accept Ether at all. Any transfer will revert. This is a common source of bugs when integrating with contracts that send Ether back to callers.

Summary

receive() handles plain Ether transfers with empty msg.data. fallback() handles everything else: unknown function calls and Ether transfers with data when no receive() exists. Having both gives you clean separation between the two cases. Having only one or the other has specific tradeoffs worth understanding before you deploy.