Majority Games Disclosed Report

The ProportionalToXPReward reward strategy fails to validate totalXP values during reward calculation. Both division by zero (when totalXP = 0) and overflow from excessively large totalXP can occur. In both cases, rewards cannot be claimed, causing the entire prize pool to become permanently locked.

Reward computation formulas do not validate totalXP:

reward = userXP * prizePool / totalXP;

rewards[i] = xps[i] * prizePool / totalXP;

• If totalXP == 0 → division by zero revert.
• If totalXP is extremely large (e.g., 2^255 provided by the asserter) → userXP * prizePool underflows effectively to zero, and reward distribution breaks.

Impact

• Complete loss of access to the prize pool for winners.
• Severity is Critical, since the entire session pool can be locked or made unclaimable.
• Example: In a $50,000 game, all $50,000 remain locked in the contract.

Mitigation

• Enforce validation of totalXP:

  require(totalXP > 0 && totalXP <= MAX_REASONABLE_XP, "Invalid total XP");
  

• Enforce reasonable bounds on XP tiers in setXPTiers.

---

Attack steps

1. A session is created with ProportionalToXPReward as the reward strategy.

2. Contestants join and participate normally.

3. When results are submitted:

   • Case A (totalXP = 0): Asserter sets XP values to 0.
   • Case B (totalXP = max): Asserter sets XP values to extremely large numbers such as 2^255.

4. UMA oracle finalizes the assertion (if undisputed).

5. During claimRewards, getReward or getRewards executes division with invalid totalXP:

   • Case A → division by zero revert.
   • Case B → reward values collapse to 0 due to overflow/precision loss.

6. In both cases, all winners are blocked from claiming rewards.

Coded POC attached - Please refer @audit comments