The commitMove() function allows a player to commit a move even if the opponent hasn’t joined the game yet. While there’s a check to ensure playerB exists when playerA commits, there is no check to ensure playerA exists when playerB commits. This results in potential game inconsistencies.
In the commitMove() function, players are allowed to commit their move after game creation. However, the function does not strictly verify that both players (i.e., playerA and playerB) have joined the game before allowing a move to be committed.
The only partial validation is that playerB must not be address(0) if the caller is playerA. There is no symmetric check ensuring that playerA exists if playerB commits first, nor is there a strong guarantee that both players are indeed set before any commitment is accepted.
This opens the possibility for an incomplete or invalid game state to proceed to the commitment phase.
If a commitment is made before both players are present, it may result in:
A one-sided lock of a player’s move commitment without the ability to proceed.
Inconsistencies or vulnerabilities during the reveal or payout phase if assumptions about two-player presence are violated.
Potential griefing attacks, where one player commits and waits indefinitely, blocking refunds or resolution.
** POC
and commits before playerA is set, the game could proceed to a Committed state with only one player present — breaking assumptions in later logic.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.