Describe the normal behavior in one or more sentences: As per protocol, any player(non-current king) should successfully claimThrone() by sending >= cliamFee, becoming the new currentKing. This starts with the first claim (from initial address(0) king) to bootstrap the game, allowing subsequent overthrows to build the pot and tirgger grace period mechanic for winner declaration.
Explain the specific issue or problem in one or more sentences: Instead, all claims revert due to the inverted logic, preventing the first king from being set and locking the game in an unplayable state indefinitely. This causes a permanent DoS: Pot remains 0, totalClaims unchanged, grace/winner funcs inert—even overpaying or multi-player attempts fail, wasting user gas and eroding trust in the protocol's competitiveness.
Likelihood:
Reason 1 : Occurs immediately on deployement for first claim (currentKing=address(0)!=msg.sender always true for non-zero addresses).
Reason 2 : Persists post-any hypothetical claim (new players != currentKing revert). No "if" avoidance-100% reproducible.
Impact:
Impact 1 : Permanent DoS - pot never accumulates, grace/winner mechanics inert.
Users waste gas on reverts, trust lost.
Impact 2 : Deployer cannot fix mid-game(require migration), eroding ecosystem confidence.
Real-World: Similar flips in games lead to refunds/backlash, dropping palyer base 50%+.
This Foundry test deploys the game and simulates claim attempts from initial state (currentKing=address(0)), using vm.prank/expectRevert to catch the inverted logic failure. It asserts unchanged state post-revert (no king/pot progress), proving permanent DoS.
This flips the logic to match spec (block re-claims by current king, allow others), enabling first/subsequent claims without altering gas (~same opcode).
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.