Sparkn

Summary

At present, there is a presumption of trust within the protocol in the word of the Sponsors when they claim to have sent a quantity of an ERC20 token to the proxy contract.
There is currently no way to view the ERC20 balances of proxy contract and hence verify what the Sponsors purport to have done.
Sponsors may or may not include the Organizer of the contest and this vulnerability may be exploited to sabotage a contest or to under-reward winners.

Vulnerability Details

Scenario 1

Consider a contest where the publicly declared parameters of a competition dictate there will be a prize fund of 3 DAI with 3 winners selected and each winner will receive an equal share or (3 DAI - COMMISSION_FEE) / 3 each.

After the contest is set; two supporters claim to have sent 1.5 DAI each to fund the contest. In reality Supporter1 has sent 1.3 DAI and Supporter2 has sent 0.1 DAI.

When any of the three functions listed below are called in ProxyFactory.sol there is only a check that the token to be distributed has a balance greater than zero. So the Organizer cannot be confident that the contest is adequately funded which may leave winners under rewarded.

This could leave the Organizer in a position where they have to make up the difference from their own pocket leaving them with finanical losses and administrative overhead as they would need to manually perform this action and communicate with the under-rewarded winners.

Three Functions:

1 deployProxyAndDistribute
2 deployProxyAndDistributeBySignature
3 deployProxyAndDistributeByOwner

Scenario 2

Consider a contest where the publicly declared parameters of a competition dictate there will be a prize fund of 10 DAI with 1 Winner so the sole winner should receive (10 DAI - COMMISSION_FEE).

The Organizer in this case is the only Sponsor and they fund the proxy contract with .0000000001 DAI.

When the Organizer calls deployProxyAndDistribute the proxy contract will be deployed and the funds will be deployed as (.0000000001 DAI - COMMISSION_FEE). The check in the _distribute function will not revert the transaction if (totalAmount == 0) revert Distributor__NoTokenToDistribute()

So the Organizer can essentially gain participation off the Supporters without adequately reimbursng them.

Impact

The absence of a transparent mechanism to view the ERC20 balances of a proxy contract introduces a significant risk to the integrity and fairness of contests held within the protocol.

1. Sponsors misrepresenting the actual funds sent could lead to financial losses for the winners.

2. Without a way to verify the claims made by the Sponsors, the protocol becomes less transparent, which may diminish participant's engagement.

3. The Organizer has no way to ensure that a contest is adequately funded before resolving it which could lead to both finanical losses and administrative overhead.

4. Malicious actors could exploit the lack of transparency to sabotage contests by funding them inadequately deterring good faith actors from engaging with the platform.

Tools Used

Manual Review
Foundry

Recommendations

A new function in proxyFactory.sol called checkBalance which can be called before resolving contests to ensure that the amount of ERC20 which has been sent to the contract matches the stated parameters of the contract. Given that the proxy contract address is known before deployment, it can be used as a parameter to call the balanceOf function in the ERC20 token contract.

As a bonus this function could further be used at any time to check if there are balances of other tokens in the contract and hence do the necessary administrative work to transfer the balances out. Contracts cannot restrict what tokens are sent to it and there is a possibility that more than one token could be sent to it though contests can only be resolved with the distribution of a single token

Could be used as a check; passing in the minimum minTokenAmount per contest params: