MyCut

Summary

The current implementation of the `Pot` contract does not transfer the required tokens into the contract upon deployment. Instead, the funding is expected to happen later via a separate `fundContest` function called by the `ContestManager` contract. This approach introduces a potential risk where the `fundContest` function may never be called, leaving the `Pot` contract without the necessary tokens to fulfill its purpose.

Vulnerability Details

This issue becomes critical when the 90-day period has elapsed, and users attempt to claim their rewards. If the `Pot` contract was never funded, no token transfers will occur, and claimants will not receive any rewards despite their eligibility. Additionally, the contract's `closePot` function, which is meant to distribute remaining rewards or return them to the Contest Manager, would be ineffective without any tokens to transfer.

Impact

• Token Loss Risk: If the `Pot` contract is not funded, claimants will not receive their rewards after calling the `claimCut`, leading to potential dissatisfaction and loss of trust in the system.

• Financial and Reputational Impact: The inability to distribute rewards as expected could lead to legal or financial consequences, as well as damage to the platform's reputation.

• Inactive or Unfunded Contract: The contract could remain inactive for the duration of the contest, rendering the contest meaningless as no rewards can be distributed.

Proof of Concept

A test was written to verify the balance of the Pot contract after its deployment:

This test confirms that the `Pot` contract has a zero balance immediately after deployment, as the constructor does not include any token transfer mechanism.

Tools Used

Manual Review

Foundry Testing

Recommendations

1. Mandatory Initial Funding:

Modify the `Pot` contract's constructor to include a token transfer using `transferFrom` to ensure that the contract is funded with the required tokens immediately upon deployment. This would require prior approval from the token holder (likely the Contest Manager) to transfer the tokens. Example:

2 Fail-safe Mechanism:

Implement a fail-safe mechanism to check the balance of the contract before allowing any claims. If the contract is not funded, users should be notified, and appropriate actions should be taken to either fund the contract or cancel the contest.

By implementing these mitigations, the risk of an unfunded `Pot` contract is eliminated, ensuring that the contest can proceed smoothly and rewards can be distributed as intended.