Summary:

The protocol does not strictly enforce matching game formats (ETH-based vs. token-based) during the join phase, allowing players to join a game using a different asset type than intended. This can lead to unfair fee application and potential economic exploitation.

Vulnerability Details:

A user can create a game with ETH via createGameWithEth and another user can join using a token via joinGameWithToken because there is no shared flag or enforcement indicating which type of game it is.

The only implicit check is game.bet == 0 for token-based games, which is not a robust or explicit indicator of game format.

If a user joins an ETH-based game with a token or vice versa, one party may pay a protocol fee while the other does not, leading to inconsistent fund handling and potential exploitation.

Impact:

Unfair Fee Exemption: Token-based winners don’t pay fees while ETH-based winners do.

Cross-Join Vulnerability: Allows players to abuse the system by joining in a way that avoids fees.

Game Inconsistency: Undermines the core rules of the protocol by mixing incompatible game types.

Tools Used: Manual Review

Recommendations:

Introduce a new GameType enum (ETH, TOKEN) and store it in the Game struct.

During both game creation and joining, enforce strict matching based on this GameType.

Apply fee logic consistently based on the game type, ensuring fairness.

Add a check in both joinGameWithEth() and joinGameWithToken() to ensure Player B's stake format matches Player A's stake format. Additionally, enforce game.playerB == address(0) to prevent race conditions or overwrite.