# 41291 sc insight winner selection vulnerability in yeetback contract allows multiple reward for the same lucky winner ## #41291 \[SC-Insight] Winner Selection Vulnerability in Yeetback Contract Allows Multiple Reward for the Same Lucky Winner **Submitted on Mar 13th 2025 at 12:16:19 UTC by @perseverance for** [**Audit Comp | Yeet**](https://immunefi.com/audit-competition/audit-comp-yeet) * **Report ID:** #41291 * **Report Type:** Smart Contract * **Report severity:** Insight * **Target:** * **Impacts:** * Theft of unclaimed yield * Theft of unclaimed royalties ### Description ## Description ### Brief/Intro The Yeetback contract implements a winner selection mechanism where 10 winners are chosen from participants in each round to receive equal portions of the pot. However, due to a flaw in the winner selection algorithm, the same participant can be selected multiple times, allowing them to claim multiple rewards. ### The vulnerability #### Vulnerability Details In the `draftWinners` function of the Yeetback contract, winners are selected using the following logic: ```solidity for (uint256 i; i < nrOfWinners; i++) { uint256 randomDataNumber = uint256(keccak256(abi.encodePacked(randomNumber, i))); uint256 winningYeetIndex = randomDataNumber % nrOfYeets; // index of the winning yeet address winnerAddress = yeetsInRound[round][winningYeetIndex]; // Update amountToWinners and amountOfWins amountOfWins[round][winnerAddress] += 1; emit YeetbackWinner(round, winnerAddress, winnings, winningYeetIndex); } ``` The contract selects 10 winners regardless of the number of participants (`nrOfYeets`). Each duplicate selection increases the winner's `amountOfWins` count, allowing them to claim multiple portions of the reward pot. **The duplicate is not expected by the game theory and users as the document of Yeet stated: 20% of the prize pool is distributed via verifiably random lottery to 10 participating addresses** . Reference: The vulnerability exists in some scenarios: * Scenario 1: * If the `nrOfYeets` is less than 10, the modulo operation (`randomDataNumber % nrOfYeets`) will inevitably produce duplicate indices. Probably this scenarios is not high as the number of participants in the game usually higher than 10. But still this can happen. * In scenario 2 : If `nrOfYeets` is greateer than 10, that scenario is more likely to happen * There is no check to prevent the same address from being selected multiple times, so there is probability that the winningYeetIndex is duplicated multiple times. The smaller the nrOfYeets, the higher the probability of duplicates. ## Impacts ### About the severity assessment This is a High severity issue because: 1. It directly affects the economic fairness of the protocol 2. It can lead to unfair distribution of reward when the number of participants is small 3. The impact is more severe in early rounds or when participation is low **The duplicate is not expected by the game theory and users as the document of Yeet stated: 20% of the prize pool is distributed via verifiably random lottery to 10 participating addresses** . Reference: Bug Severity: High I map the impact to the closest listed impact as this is related to unfair distribution of reward, lucky winner Theft of unclaimed royalties Theft of unclaimed yield ## Recommendation * Take both scenarios in the algorithm * Implement the algorithm to avoid duplicates to avoid rewarding the same address multiple times. ### Proof of Concept ## Proof of Concept ### Scenario 1: Small Number of Participants (nrOfYeets < 10) 1. Alice, Bob, and Charlie participate by [yeet()](https://github.com/immunefi-team/audit-comp-yeet/blob/main/src/Yeet.sol#L265) in round 1. Suppose the nrOfYeets is 3 participants. The contract adds them to `yeetsInRound[1]` array 2. After the Round1 ends and cooldown period, a user call ["restart()"](https://github.com/immunefi-team/audit-comp-yeet/blob/main/src/Yeet.sol#L353) in Yeet.sol to start Round 2. The contract calls `addYeetback()` with 100 BERA as the pot value 3. The `draftWinners()` function is called back from [`entropyCallback()`](https://github.com/immunefi-team/audit-comp-yeet/blob/main/src/Yeetback.sol#L159) to select 10 winners 4. Due to modulo operation with only 3 participants: * `randomDataNumber % 3` will only produce values 0, 1, or 2 * Some addresses must be selected multiple times to reach 10 winners 5. Alice is selected 4 times, Bob 3 times, and Charlie 3 times 6. When claiming rewards: * Alice claims 4/10 of the pot (40 BERA) * Bob claims 3/10 of the pot (30 BERA) * Charlie claims 3/10 of the pot (30 BERA) 7. This results in unfair distribution where Alice receives more. ### Scenario 2: Large Number of Participants (nrOfYeets > 10) 1. 100 participants join Round 2 of Yeet 2. After the Round2 ends and cooldown period, a user call ["restart()"](https://github.com/immunefi-team/audit-comp-yeet/blob/main/src/Yeet.sol#L353) in Yeet.sol to start Round 3. The contract calls `addYeetback()` with 100 BERA as the pot value 3. The `draftWinners()` function is called back from [`entropyCallback()`](https://github.com/immunefi-team/audit-comp-yeet/blob/main/src/Yeetback.sol#L159) to select 10 winners 4. Due to the random modulo operation with 100 participants: * `randomDataNumber % 100` can produce any value from 0 to 99 * There is a probability that the same index is selected multiple times 5. By chance, index 42 is selected twice: * First selection: `randomDataNumber1 % 100 = 42` * Second selection: `randomDataNumber2 % 100 = 42` 6. The participant at index 42: * Gets their `amountOfWins` increased twice * Can claim 2/10 of the pot (20 BERA) instead of 1/10 (10 BERA) 7. This creates an unfair advantage for the lucky participant who was selected multiple times In both scenarios, the core issue is the lack of check for duplicate selections, allowing participants to receive multiple portions of the reward pot. The impact is more severe in Scenario 1 where duplicates are guaranteed, while Scenario 2 shows how the vulnerability can still affect fair distribution even with many participants.