Summary

The protocol supports USDT and USDC tokens both which support blacklisting functionality. The airdropERC20 function stops executing when encountering a blacklisted address, causing gas wastage and potential attack vectors.

Vulnerability Details

The airdropERC20 function halts if any call to transfer tokens fails, which can happen if an address is blacklisted. This means that for an airdrop to 5000 users, if 20 users are blacklisted (less than 0,5%), the function would need to be executed 20 times, each time removing the blacklisted address until all legitimate addresses receive the airdrop. Also an attacker can setup many blacklisted addresses as legitimate receivers of the airdrop of a protocol. These issues can cause the protocol sender to waste a lot of gas.

Now there might be a way for the protocol sender to know beforehand which address is blacklisted and remove them. Which obviously only a small number would know how to do it. However, in an automated setting, let's say a keeper that is set up to periodically send the airdrop to registered addresses, these issues are still valid in this case.

Current code that is programmed to revert when a call fail :

TSender.sol

Huff contracts

Impact

Gas wastage in case of multiple re-runs especially for a larger number of recipients.

Tools Used

Manual review

Recommendations

Consider modifying the function to continue executing even if a transfer to a specific address fails. Track the failed transfers and return the total amount not sent at the end of the process back to the protocol sender. This method is probably a little bit less gas efficient since there will one more memory variable to track, and one more call (that sends the remainder back to the caller) at the end in case one or more calls failed. However, it makes sure that the caller is not wasting any gas trying to re-run the function.