Summary

The internal _finishGame function incorrectly handles the prize distribution for token-based games. Instead of transferring the WinningTokens previously deposited by the players to the winner, it mints two new tokens, leaving the original deposited tokens locked within the contract.

Vulnerability Details

When players participate in a token-based game (identified by game.bet == 0), they each deposit 1 WinningToken into the RockPaperScissors contract via createGameWithToken and joinGameWithToken. At this point, the contract holds 2 tokens intended as the prize pool for that specific game.

However, when a winner is determined and _finishGame is called, the logic for token games executes the following line:

The winningToken.mint(_winner, 2); call creates two entirely new WinningTokens and sends them to the winner. It completely ignores the two tokens that were deposited by Player A and Player B, which remain held by the RockPaperScissors contract address.

Impact

This vulnerability has two primary negative impacts:

• Locked Tokens: The 2 WinningTokens deposited by the players for each completed token game become permanently locked within the RockPaperScissors contract. There is no mechanism to withdraw or utilize these specific deposited tokens. Over time, the contract will accumulate a growing balance of unusable tokens.

• Unnecessary Token Inflation: The WinningToken supply is inflated by 2 tokens for every completed token game. This contradicts the apparent intention of using deposited tokens as the prize pool and devalues existing tokens through unnecessary supply increase.

• Deviation from Expected Behavior: Users expect the prize to consist of the tokens staked by the players, not newly created ones.

Tools Used

• Manual code review.

Recommendations

The _finishGame function should be modified to transfer the existing tokens held by the contract to the winner, rather than minting new ones.

Replace the mint call with a transfer call: