MyCut

Summary:

High Severity: The contract does not check for duplicate entries in the players array during initialization. If a player appears multiple times with different rewards, the current implementation overwrites the previous reward value in the playersToRewards mapping instead of adding the rewards together. This results in incorrect reward allocation, where the player could receive either less or more than their rightful total rewards, leading to financial discrepancies.

Vulnerability Details:

In the constructor of the Pot contract, player rewards are initialized using a loop that assigns rewards from the i_rewards array to the players in the i_players array:

Since there is no check for duplicate entries in the i_players array, a player listed multiple times with different rewards will have their reward overwritten in the playersToRewards mapping. Instead of adding the rewards for duplicate entries, the mapping only retains the last specified reward. This leads to an incorrect total reward for that player, as earlier rewards are overridden.

Impact:

The impact of this vulnerability includes:

• Incorrect Reward Allocation: A player appearing multiple times in the i_players array may end up receiving either more or less than their total calculated reward, depending on the order of entries.

• Financial Discrepancies: This could lead to significant financial discrepancies and dissatisfaction among players who expect to receive their total allocated rewards.

• Loss of Trust: The integrity of the reward distribution process is compromised, potentially leading to a loss of trust in the contract's fairness.

Tools Used:

• Manual Review

Recommendations:

To efficiently resolve this issue, modify the reward assignment in the constructor to accumulate rewards for each player instead of overwriting them. This ensures that players receive the total sum of all their rewards, even if they appear multiple times in the i_players array.

Updated Constructor with Accumulation Logic:

By changing playersToRewards[i_players[i]] = i_rewards[i]; to playersToRewards[i_players[i]] += i_rewards[i];, the contract correctly accumulates the total rewards for each player, ensuring accurate reward distribution without the need for additional gas-consuming checks for duplicates.

This approach is more gas-efficient than adding extra checks or requiring unique entries and still resolves the issue effectively.