Submission Details
Impact:
Likelihood:
`Game::receive` Accounting Mismatch From Direct Transfers
Description
Sending a direct ETH transfer to the contract's address will result in funds being stuck as there is no mechanism to prevent this. The issue is caused by the
Game::receivefunction.
@> receive() external payable {}
Risk
Likelihood:
Whenever a player decides to send ETH directly to the contract
Impact:
-
Stuck funds
-
Contract balance is different from the tracked balances
Proof of Concept
function testAccountingMismatch() public {
assertEq(game.getContractBalance(), 0);
assertEq(game.pot() + game.platformFeesBalance(), 0);
// Someone sends 5 ETH directly
payable(address(game)).transfer(5 ether);
// Now: Contract balance = 5 ETH, tracked = 0
uint256 contractBalance = game.getContractBalance();
console2.log("Contract balance:", contractBalance);
assertEq(game.getContractBalance(), 5 ether);
uint256 accountingBalance = game.pot() + game.platformFeesBalance();
console2.log("Accounting Balancee:", accountingBalance);
assertEq(game.pot() + game.platformFeesBalance(), 0);
// 5 ETH is permanently stuck
}
Recommended Mitigation
- receive() external payable {}
OR
implement a recovery function
Updates
Appeal created
inallhonesty about 2 months ago
Submission Judgement Published Reason: Non-acceptable severity
Assigned finding tags:
Direct ETH transfers - User mistake
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.
Rewards breakdown
nSLOC
181This contest has a flat reward structure with the following payouts:
100 EXP
20 EXP
2 EXP
Live
The contest is live. Earn rewards by submitting a finding.
Appeals
This is your time to appeal against judgements on your submissions.
Appeals Review
Appeals are being carefully reviewed by our judges.