Solhint: Why should I avoid multiple calls of "send" in a single transaction?

Question

function withdrawAll() public payable onlyOwner {
    uint256 _each = address(this).balance / 4;
    require(payable(t1).send(_each), "Account is being paid out");
    require(payable(t2).send(_each), "Account is being paid out");
    require(payable(t3).send(_each), "Account is being paid out");
    require(payable(t4).send(_each), "Account is being paid out");
}

Here the function that is giving me the linter warning. I am just wondering what the severity is for this warning. Linter: Avoid multiple calls of "send" method in single transaction [multiple-sends] Is this not how airdrops work? Is there a higher chance for this transaction to fail for some reason? I cannot find any documentation on this subject, so I am going to shrug it off for now as I am only deploying on testnets right now.

Answer 1

You are sending the native asset (Ether). You don't usually send the native asset in airdrops, but some token.

The main (technical) difference is that the receiving contract can (potentially) trigger re-entrancy vulnerabilities if you send the native asset, but can't do that if you send tokens. Another issue is what should happen if the transfer fails? You should check the return value and do something if it fails.

If possible, allow your users to withdraw their assets from the contract instead of pushing them. That's better security-wise and that way you don't have to pay for the gas of sending the assets.

The send you use only forwards 2300 gas, which isn't enough to trigger any vulnerabilities. On the other hand, you also shouldn't rely on any constant gas amounts. In general, it should be you who decides how much gas to forward (if any). More info here: https://consensys.net/diligence/blog/2019/09/stop-using-soliditys-transfer-now/ (applies also to send).

Sending the native asset to an address can fail, for example, if the receiver is a contract which simply reverts upon receiving assets.

In summary: don't push the native asset to users, if possible. If you have to do that, decide what to do if the transfer fails.