If there are too many holders(More than 1000, which is not unrealistic) & the number of reward tokens is more than a couple, because of the nested for-loops and constant sloads(even though some of them will be warm) + stores(most of them will be from non-zero to non-zero value, which is still 5k gas on write though), a DoS can occur. The contract should be heavily optimized in order to save the redundant sloads, but even then DoS might occur, so a public/external function should be exposed so that holders can themselfes claim their rewards, therefore DoS/out of gas errors can be prevented
Tools Used
Mannual review
Recommended Mitigation Steps
Use Pull instead of Push, when it comes to distributing rewards
Lines of code
https://github.com/code-423n4/2024-02-althea-liquid-infrastructure/blob/main/liquid-infrastructure/contracts/LiquidInfrastructureERC20.sol#L213-L231
Vulnerability details
Impact
If there are too many
holders
(More than 1000, which is not unrealistic) & the number of reward tokens is more than a couple, because of the nested for-loops and constant sloads(even though some of them will be warm) + stores(most of them will be from non-zero to non-zero value, which is still 5k gas on write though), a DoS can occur. The contract should be heavily optimized in order to save the redundant sloads, but even then DoS might occur, so a public/external function should be exposed so that holders can themselfes claim their rewards, therefore DoS/out of gas errors can be preventedTools Used
Mannual review
Recommended Mitigation Steps
Use
Pull
instead ofPush
, when it comes to distributing rewardsAssessed type
DoS