Bird
Raised Fist0
Blockchain / Solidityprogramming~5 mins

Receive and fallback functions in Blockchain / Solidity

Choose your learning style10 modes available
Introduction

Receive and fallback functions let a smart contract accept money and handle calls that don't match any other function.

When your contract needs to accept plain Ether transfers without data.
When you want to handle unexpected calls or wrong function names gracefully.
When you want to log or react to any call that doesn't match existing functions.
When you want to prevent Ether from being sent to your contract accidentally.
When you want to provide a default behavior for unknown function calls.
Syntax
Blockchain / Solidity
receive() external payable {
    // code to handle plain Ether transfers
}

fallback() external payable {
    // code to handle calls with data or unknown functions
}

The receive function is called when the contract receives Ether with empty calldata.

The fallback function is called when no other function matches or when Ether is sent with data.

Examples
This receive function allows the contract to accept Ether transfers without any data.
Blockchain / Solidity
receive() external payable {
    // Accept Ether and do nothing else
}
This fallback function logs when it is called, useful for debugging unexpected calls.
Blockchain / Solidity
fallback() external payable {
    // Log that fallback was called
    emit FallbackCalled(msg.sender, msg.value);
}
This example accepts Ether via receive and rejects unknown function calls with an error.
Blockchain / Solidity
receive() external payable {
    balance += msg.value;
}

fallback() external {
    revert("Function does not exist");
}
Sample Program

This contract has a receive function that emits an event when Ether is sent without data. The fallback function emits an event when the contract receives calls with unknown functions or data.

Blockchain / Solidity
pragma solidity ^0.8.0;

contract ReceiveFallbackExample {
    event Received(address sender, uint amount);
    event FallbackCalled(address sender, uint amount, bytes data);

    receive() external payable {
        emit Received(msg.sender, msg.value);
    }

    fallback() external payable {
        emit FallbackCalled(msg.sender, msg.value, msg.data);
    }
}
OutputSuccess
Important Notes

Only one receive function is allowed per contract.

If receive is not defined, fallback handles all calls including plain Ether transfers.

Both functions must be marked external and payable to accept Ether.

Summary

Receive function handles plain Ether transfers with empty data.

Fallback function handles calls with unknown functions or data.

Use these functions to safely accept Ether and handle unexpected calls.

Practice

(1/5)
1.

What is the main purpose of the receive() function in a Solidity contract?

easy
A. To reject all incoming Ether transfers
B. To handle calls to unknown functions with data
C. To execute code when a contract is created
D. To handle plain Ether transfers without any data

Solution

  1. Step 1: Understand the role of receive()

    The receive() function is designed to accept Ether sent to the contract without any accompanying data.
  2. Step 2: Differentiate from fallback function

    The fallback function handles calls with data or unknown function calls, while receive() is only for plain Ether transfers.
  3. Final Answer:

    To handle plain Ether transfers without any data -> Option D
  4. Quick Check:

    receive() handles plain Ether = C [OK]
Hint: receive() handles Ether with no data, fallback handles calls with data [OK]
Common Mistakes:
  • Confusing receive() with fallback()
  • Thinking receive() handles calls with data
  • Assuming receive() rejects Ether
2.

Which of the following is the correct syntax for a receive() function in Solidity?

?
easy
A. receive() external payable {}
B. function receive() public {}
C. fallback() external payable {}
D. function receive() external {}

Solution

  1. Step 1: Recall receive() function syntax

    The receive() function must be declared without the function keyword, must be external and payable.
  2. Step 2: Check each option

    receive() external payable {} matches the correct syntax. Options using the function keyword are invalid, as are those lacking payable or using fallback instead of receive.
  3. Final Answer:

    receive() external payable {} -> Option A
  4. Quick Check:

    receive() syntax requires external payable = B [OK]
Hint: receive() has no function keyword, must be external payable [OK]
Common Mistakes:
  • Adding 'function' keyword to receive()
  • Omitting 'payable' modifier
  • Confusing fallback() with receive()
3.

Consider this Solidity contract snippet:

contract Test {
    event Log(string func);

    receive() external payable {
        emit Log("receive");
    }

    fallback() external payable {
        emit Log("fallback");
    }
}

What event is emitted when someone sends 1 Ether with empty data?

medium
A. "receive"
B. "fallback"
C. No event emitted
D. Compilation error

Solution

  1. Step 1: Identify the call type

    Sending Ether with empty data triggers the receive() function if it exists.
  2. Step 2: Check which event is emitted

    The receive() function emits the event with "receive" string.
  3. Final Answer:

    "receive" -> Option A
  4. Quick Check:

    Empty data + Ether triggers receive() = "receive" [OK]
Hint: Empty data + Ether calls receive(), else fallback [OK]
Common Mistakes:
  • Assuming fallback() triggers on empty data
  • Thinking no event is emitted
  • Confusing receive() and fallback() roles
4.

Given this contract snippet, what is the error?

contract Example {
    fallback() external {
        // code
    }

    receive() external {
        // code
    }
}
medium
A. receive() cannot be declared after fallback()
B. Both fallback and receive must be payable to accept Ether
C. fallback() must have the function keyword
D. No error, code is correct

Solution

  1. Step 1: Check payable modifiers

    To accept Ether, both receive() and fallback() must be marked payable.
  2. Step 2: Analyze given code

    Both functions lack payable, so contract cannot receive Ether via these functions.
  3. Final Answer:

    Both fallback and receive must be payable to accept Ether -> Option B
  4. Quick Check:

    Missing payable means no Ether acceptance = A [OK]
Hint: Missing payable means no Ether accepted by receive or fallback [OK]
Common Mistakes:
  • Thinking order of functions matters
  • Assuming fallback needs 'function' keyword
  • Ignoring payable requirement
5.

You want your contract to accept Ether sent with or without data, and log which function was called. Which is the best way to implement this?

?
hard
A. Do not implement receive or fallback; use a regular payable function instead
B. Implement only receive() external payable function and ignore fallback
C. Implement both receive() external payable and fallback() external payable functions, each emitting a distinct event
D. Implement only fallback() external payable function to handle all cases

Solution

  1. Step 1: Understand Ether transfer scenarios

    Ether can be sent with empty data (calls receive) or with data (calls fallback).
  2. Step 2: Implement both functions to handle all cases

    Implementing both receive() and fallback() as external payable lets the contract accept Ether in both cases and emit distinct events.
  3. Final Answer:

    Implement both receive() external payable and fallback() external payable functions, each emitting a distinct event -> Option C
  4. Quick Check:

    Both functions needed for all Ether types = D [OK]
Hint: Use both receive() and fallback() payable to cover all Ether sends [OK]
Common Mistakes:
  • Implementing only one function and missing some Ether transfers
  • Ignoring fallback for calls with data
  • Using regular payable function instead of receive/fallback
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard