Mystery Box

Description

The addReward function in the MysteryBox contract allows the contract owner to add new rewards to the rewardPool. However, the openBox function, which determines the reward a user receives when opening a box, relies on a series of hard-coded if-else statements that only account for the initially defined rewards (“Coal”, “Bronze Coin”, “Silver Coin”, “Gold Coin”). Consequently, any new rewards added through the addReward function are not considered or distributed when users open boxes. This discrepancy creates a situation where the rewardPool can contain rewards that are never actually awarded to users.

Impact

Allowing the addition of new rewards without integrating them into the reward distribution mechanism renders these rewards ineffective. Users will not have the opportunity to receive the newly added rewards, leading to confusion and dissatisfaction. This can erode trust in the contract’s functionality and fairness, as users may perceive the system as misleading or broken. Additionally, the contract owner might face challenges in managing and updating the reward system, knowing that newly added rewards will not be utilized. Over time, this issue can diminish user engagement, reduce box sales, and compromise the overall sustainability and reputation of the contract.

PoC

• Deploy the MysteryBox contract with the initial rewards: “Gold Coin” (0.5 ether), “Silver Coin” (0.25 ether), “Bronze Coin” (0.1 ether), and “Coal” (0 ether).

• The contract owner calls the addReward function to add a new reward, for exampele:

• A user purchases and opens a box by calling the buyBox and openBox functions.

Observation:

• Despite the addition of “Platinum Coin” to the rewardPool, the user never receives “Platinum Coin” when opening a box. The openBox function’s logic does not account for the newly added reward, limiting the possible rewards to the initially defined ones.

Outcome:

• The newly added “Platinum Coin” remains unused and undistributed, highlighting the disconnect between the addReward function and the reward distribution logic within openBox.

Tools Used

• Manual Code Review:

Analyzing the smart contract’s source code to identify inconsistencies between the addReward function and the openBox reward distribution logic.

Recommendations

• Dynamic Reward Distribution Mechanism:

• Refactor the openBox function to dynamically handle all rewards present in the rewardPool. Instead of using hard-coded if-else statements, implement a system that iterates through the rewardPool and assigns rewards based on their defined probabilities or weights.