Open hats-bug-reporter[bot] opened 4 months ago
I get the issue, but also, being that the client builds the claim bundles, if multiple are used at the same time and one fails, it's also possible to exclude the failing claim from the array and proceed with all the others, or go about it one-by one (the claim rewards function can be called with one bundle at a time, and no loop is involved there).
Github username: -- Twitter username: -- Submission hash (on-chain): 0x8b8b1f5a83a884203e202d43e55b44f7399a774dd193897c6e98a017b51f251e Severity: low
Description: Description
Performing token transfers in a loop in a Solidity contract is generally not recommended due to various reasons. One of these reasons is the "Fail-Silently" issue.
In a Solidity loop, if one transfer operation fails, it causes the entire transaction to fail. This issue can be particularly troublesome when you're dealing with multiple transfers in one transaction. For instance, if you're looping through an array of recipients to distribute dividends or rewards, a single failed transfer will prevent all the subsequent recipients from receiving their transfers. This could be due to the recipient contract throwing an exception or due to other issues like a gas limit being exceeded.
Moreover, such a design could also inadvertently lead to a situation where a malicious contract intentionally causes a failure when receiving Ether to prevent other participants from getting their rightful transfers. This could open up avenues for griefing attacks in the system.
Resolution: To mitigate this problem, it's typically recommended to follow the "withdraw pattern" in your contracts instead of pushing payments. In this model, each recipient would be responsible for triggering their own payment. This separates each transfer operation, so a failure in one doesn't impact the others. Additionally, it greatly reduces the chance of malicious interference as the control over fund withdrawal lies with the intended recipient and not with an external loop operation.
Attachments
['298']
['298']
['165']
['165']
['193']