In the _handleTie()
function, ETH refunds to both players are attempted using low-level .call{value:}
. If either transfer fails, the function reverts entirely due to the require(successA && successB, "Transfer failed");
check. This causes all refunds to fail, even if one transfer was successful, potentially locking funds in the contract permanently.
If either playerA
or playerB
cannot receive ETH (e.g., a contract with a failing receive()
function), the entire transaction reverts.
No alternative handling (e.g., retry logic or partial refunds) is implemented.
If one of the players is a contract without a payable fallback or actively reverts, both players are denied their refund.
This can result in locked ETH with no recovery mechanism unless a separate admin refund is added.
A malicious player could intentionally deploy a rejecting contract to block refunds for others.
manual, foundry
allow partial refund
Handle transfer seperately with event
Malicious player wins a game using a contract that intentionally reverts when receiving ETH, the entire transaction will fail
Malicious player wins a game using a contract that intentionally reverts when receiving ETH, the entire transaction will fail
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.