Missing Logic to calculate and assign the previousKingPayout
in the Game::claimThrone
function leaving no ETH for the previous King.
When a new player claims the throne by paying the required claimFee
, a portion of their payment should be allocated to the previous king as a payout, the platform takes a small percentage as a fee, and the rest goes into the prize pot. This incentivizes participation and ensures fair distribution of funds between players and the platform.
The previousKingPayout
is initialized to 0 and never updated with the actual payout amount owed to the previous king. As a result, when a new player claims the throne, the previous king receives no compensation.
Likelihood:
This issue occurs whenever a user claims the throne, as the fee logic always references previousKingPayout
, which is never set or updated in the contract.
Since the contract is live and allows multiple users to claim the throne, the faulty logic is consistently triggered in every execution of the claimThrone
function, leading to loss of funds for each previous king.
Impact:
The previous king never receives any payout , resulting in a complete loss of funds for that user after being dethroned.
The entire claim amount is either allocated to the platform fee or the pot inaccurately, breaking the intended reward flow of the game and discouraging users from participating further.
To uncover this issue, a minor modification was made to the claimThrone()
function:
//Original condition
require(msg.sender == currentKing, "Game: You are already the king. No need to re-claim.");
//Modified for testing purposes:
require(msg.sender != currentKing, "Game: You are already the king. No need to re-claim.");
This change allowed multiple distinct users to claim the throne consecutively, which revealed that the previousKingPayout
is always zero, meaning the dethroned king receives no payout at all.
This Proof of Concept can be tested in Game.t.sol
To ensure dethroned kings are fairly compensated, the contract should:
Calculate the previousKingPayout
before assigning the new king, This could be a fixed percentage of the incoming claimFee
or based on a Formula.
Assign the payout to the correct address by updating pendingWinnings[previousKing]
before changing currentKing
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.