Summary

TSender contract assumes it’s interacting with externally owned accounts (EOAs) as recipients. However, when the TSender contract encounters a recipient address that points to another smart contract, the behavior becomes unpredictable.

Problem:

The current implementation in airdropERC20 uses a low-level call opcode to transfer tokens. This call opcode simply sends the specified amount of data (including the recipient address and amount) to the recipient address. If the recipient is a smart contract, it will interpret the data as a function call and attempt to execute the corresponding function.

Unexpected Behavior:

Wrong Function Execution: The TSender contract intends to call the transfer function of the ERC20 token contract at the recipient address. However, the recipient smart contract might have a different function with the same signature (address, uint256). This could lead to unintended consequences depending on the recipient contract's logic.

Token Not Transferred: Even if the recipient smart contract has a transfer function, it might have custom logic that prevents the transfer from happening as intended.

Reentrancy Vulnerability: Malicious recipient contracts could exploit the call by re-entering the airdropERC20 function during the transfer, potentially leading to issues like manipulating the loop or stealing funds.

2nd Problem :

When dealing with smart contract addresses, the behavior can indeed be unpredictable due to the potential execution of fallback functions or receiving hooks like onERC20Received which are part of the ERC-223 and ERC-777 token standards.

Impact on TSender Contract:

If the TSender contract sends tokens to a recipient address that implements one of these standards, the following might occur:

Unexpected Fallback Function Execution: The recipient contract's fallback function might be triggered during the transfer, potentially altering the intended behavior or even reverting the transaction.

onERC20Received Hook Interaction: If the recipient contract implements onERC20Received, it might perform custom logic based on the provided data. The TSender contract wouldn't be aware of this custom logic which could lead to unexpected outcomes.

Mitigation:

Address Type Checking: Implement checks to verify recipient addresses are EOAs before attempting transfers.

Custom Recipient Contract: Develop a custom recipient contract for specific scenarios where the airdrop targets a smart contract expecting a particular format for receiving tokens.