pot
AccountingExpected behaviour: All value held by the contract should be claimable by someone—either the current king (via pot
) or the owner (via platform fees). Sending plain ETH to the contract should increase pot
or be rejected.
Actual issue: The contract implements a bare receive()
function:
ETH sent with no calldata is accepted, but no state variable is updated. The value sits in address(this).balance
yet is excluded from:
pot
— winnings for the eventual king
platformFeesBalance
— owner withdrawals
When declareWinner()
is later called, only pot
is moved to pendingWinnings
; the stray ETH remains trapped forever.
Likelihood:
Anyone (or any bot) can send ETH to the contract at zero gas per call. It might even happen accidentally (e.g. mistaken address). Thus occurrence is high over time.
Impact:
The contract’s on-chain balance diverges from what off-chain UIs display as the pot. Users could believe more ETH is up for grabs than is actually winnable.
Locked funds lower the effective APY of the game and represent permanent value loss—griefers burn ETH to reduce everybody’s incentive.
The test below sends 1 wei directly to the contract, then shows that pot
, platformFeesBalance
, and pendingWinnings
remain zero while the contract balance increases.
Two safe options:
or, if direct sends are undesired:
Either change prevents value from becoming permanently stranded.
There is no reason for a user to directly send ETH or anything to this contract. Basic user mistake, info, invalid according to CH Docs.
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.