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.