Receive and fallback functions in Blockchain / Solidity - Step-by-Step Execution

Concept Flow - Receive and fallback functions

Contract receives Ether

↓

Is msg.data empty?

No→Call fallback()

Yes↓

Call receive()

↓

Execute function body

↓

End

When a contract receives Ether, it checks if data is sent. If no data, receive() runs; if data or no receive(), fallback() runs.

Execution Sample

Blockchain / Solidity

contract Example {
  receive() external payable {
    // handle plain Ether
  }
  fallback() external payable {
    // handle calls with data or no receive
  }
}

This contract has receive() for plain Ether and fallback() for calls with data or when receive() is missing.

Execution Table

Step	msg.data	Function Called	Action	Output
1	empty	receive()	Accept Ether with no data	Ether received
2	non-empty	fallback()	Handle call with data	Fallback logic runs
3	empty	fallback()	No receive() defined, fallback handles Ether	Ether received via fallback
4	non-empty	fallback()	Fallback called for unknown function	Fallback logic runs
5	-	-	-	Execution ends

💡 Execution stops after receive() or fallback() handles the call

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
msg.data	varies	empty	non-empty	empty	non-empty	varies
Function Called	none	receive()	fallback()	fallback()	fallback()	none

Key Moments - 2 Insights

Why does fallback() run when msg.data is empty in step 3?

Because receive() is not defined in that case, fallback() handles the Ether receipt as shown in execution_table row 3.

What happens if msg.data is non-empty but receive() exists?

Fallback() runs because receive() only handles calls with empty msg.data, as shown in execution_table row 2.

Visual Quiz - 3 Questions

Look at the execution table, which function is called when msg.data is empty and receive() exists?

A receive()

B fallback()

C constructor()

D no function

💡 Hint

Check execution_table row 1 where msg.data is empty and receive() is called

At which step does fallback() handle Ether because receive() is missing?

A Step 1

B Step 3

C Step 2

D Step 4

💡 Hint

Look at execution_table row 3 where fallback() runs with empty msg.data

If msg.data is non-empty, which function always runs according to the table?

A receive()

B constructor()

C fallback()

D no function

💡 Hint

See execution_table rows 2 and 4 where msg.data is non-empty and fallback() runs

Concept Snapshot

receive() runs when contract gets Ether with empty msg.data
fallback() runs when msg.data is non-empty or receive() is missing
Both can be payable to accept Ether
Use receive() for plain Ether transfers
Use fallback() for calls with data or unknown functions

Full Transcript

When a contract receives Ether, it checks if the data sent (msg.data) is empty. If empty and receive() exists, receive() runs to accept Ether. If msg.data is not empty or receive() is missing, fallback() runs. This lets contracts handle plain Ether transfers and calls with data differently. The execution table shows steps where receive() or fallback() is called based on msg.data. Variables msg.data and Function Called change accordingly. Key moments clarify why fallback() runs sometimes even with empty msg.data. The visual quiz tests understanding of which function runs in different cases.

Practice

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