Rock Paper Scissors

Description:

Once playerB joins a game, only playerA (the creator) has the authority to cancel it while the game remains in the Created state. If playerA becomes inactive, abandons the game intentionally, or is simply unresponsive, playerB has no way to exit the game or recover their staked ETH or tokens before the first commitMove() is made.

This creates a situation where playerB's funds can remain locked indefinitely if playerA never initiates the game. Although there is a joinDeadline, it only applies before playerB joins. Once both players are present, no timeout or cancellation mechanism is available prior to game progression.

Impact

• playerB is fully dependent on playerA's activity to proceed or cancel the game.

• ETH or tokens deposited by playerB may remain locked if playerA becomes inactive.

• Potential for griefing attacks where malicious creators trap participants.

• Negative user experience due to lack of control for playerB.

Proof of Concept:

Example Scenario:

• playerA creates a game.

• playerB joins and deposits ETH or tokens.

• playerA never calls commitMove().

• playerB cannot cancel the game or retrieve funds.

• The game remains stuck in Created state indefinitely.

Tools Used

Manual Review and Foundry

Recommendations

Implement a mechanism to protect playerB from inactivity scenarios:

Allow playerB to cancel the game if playerA does not perform any action (e.g., no commitMove()) within a reasonable timeframe after joining.
Alternatively, introduce an automatic timeout that triggers cancellation if neither player acts within a defined period after both players have joined.
This ensures fair treatment of both players and prevents unnecessary fund locking due to inactivity or malicious behavior.