Sparkn

Summary

Distribution of rewards can be DoSed through unbounded loops and blacklisted address.

Vulnerability Details

Once a contest end, the organizer or the owner is tasked to distribute the rewards to the participants and so the _distribute() function will be called in Distributor.sol.

In the _distribute() function, there can be two ways for the function to fail. Firstly, unbounded loops. The function will loop through every single winner and distribute their rewards according to the percentage.

If the length of the winners get too much, it may cause an out of gas error which will cause the entire function to fail. The function also does not allow for multiple function calls (that means that the amount of winners cannot be split into smaller array lengths and called repeatedly) because of the percentage check and the transfer of dust tokens. The protocol team seems to acknowledge this issue and mentions that this would not be the case as the winners would not be that long. However, it is hard to determine the length of winners, especially if the contests is like an audit contests where there can be many applicants.

Secondly, blacklisted tokens. If a winner is blacklisted from USDC and the rewards being distributed is USDC, the whole function will fail. The organizer cannot simply delete the user who is blacklisted from the winners array because the percentage calculation will not be accurate anymore. If there is a blacklisted winner, it is quite hard for this function to still run (organizer has to recalculate the percentage, find the blacklisted address etc)

Impact

Denial of Service when distributing tokens

Tools Used

Manual Review

Recommendations

For the first issue, the protocol team can probably set an off-chain limit to the number of participants, so that will not be a huge problem. For the second issue, in order to mitigate a blacklist address, the distribute function should be wrapped in a try check loop. If there is an instance of a failure due to blacklist, the function will still carry on and distribute the rest. This wouldn't be a problem because at the last line, the remaining tokens will be sent to the STADIUM_ADDRESS. The owner of that address can resolve the issue with the blacklisted winner by swapping the blacklisted tokens to a safer one and transferring it to the winner.