Normally, settling a raffle should not depend on the winner's ability to receive ETH in the same transaction — a prize owed should be claimable. However, in the current implementation the prize is pushed to the winner, and require(success) reverts the whole settlement when the winner cannot accept the transfer.
The vulnerability exists in PuppyRaffle.sol#L148-L153.
Root Cause: Denial of service — push payment to an arbitrary address with revert-on-failure blocking settlement.
Vulnerable Code:
Why This Is Exploitable:
Any Ethereum address can enter the raffle, including contracts that have no ETH receive path. selectWinner is permissionless, and the winner is chosen by caller/timestamp-dependent RNG. Every (caller, timestamp) pair whose index maps to the non-receiving player produces a reverting transaction: the prize transfer fails and the state reset (delete players, timer restart) is rolled back with it. The round can only settle via the remaining outcomes — with one non-receiver among four players, roughly a quarter of settlement attempts revert, wasting callers' gas.
Likelihood:
Requires at least one player to be a contract without a receive path — plausible (smart-contract wallets, multisigs) but not guaranteed in every round.
Each poisoned RNG outcome deterministically reverts; the frequency scales with the share of non-receiving players.
Impact:
Temporary, probabilistic denial of service of settlement and gas griefing for callers — not a permanent lock, since other outcomes still settle the round.
No funds are stolen; the impact is availability of round settlement.
Run: forge test --match-test testPoC_SettlementRevertsWhenWinnerCannotReceive -vv
Output (actual run):
Alice, Bob, Carol enter; the fourth slot is a contract that can call enterRaffle but has no receive()/fallback.
After duration, a caller whose (caller, timestamp) hash modulo 4 lands on index 3 calls selectWinner.
The prize call to the contract fails, require(success) reverts with "PuppyRaffle: Failed to send prize pool to winner", and the round remains unsettled.
Use a pull-payment pattern: record the prize as owed and let the winner withdraw it in a separate transaction, so settlement can never be blocked by the winner's receive behavior:
Proposed Fix:
References:
## Description If a player submits a smart contract as a player, and if it doesn't implement the `receive()` or `fallback()` function, the call use to send the funds to the winner will fail to execute, compromising the functionality of the protocol. ## Vulnerability Details The vulnerability comes from the way that are programmed smart contracts, if the smart contract doesn't implement a `receive() payable` or `fallback() payable` functions, it is not possible to send ether to the program. ## Impact High - Medium: The protocol won't be able to select a winner but players will be able to withdraw funds with the `refund()` function ## Recommendations Restrict access to the raffle to only EOAs (Externally Owned Accounts), by checking if the passed address in enterRaffle is a smart contract, if it is we revert the transaction. We can easily implement this check into the function because of the Adress library from OppenZeppelin. I'll add this replace `enterRaffle()` with these lines of code: ```solidity function enterRaffle(address[] memory newPlayers) public payable { require(msg.value == entranceFee * newPlayers.length, "PuppyRaffle: Must send enough to enter raffle"); for (uint256 i = 0; i < newPlayers.length; i++) { require(Address.isContract(newPlayers[i]) == false, "The players need to be EOAs"); players.push(newPlayers[i]); } // Check for duplicates for (uint256 i = 0; i < players.length - 1; i++) { for (uint256 j = i + 1; j < players.length; j++) { require(players[i] != players[j], "PuppyRaffle: Duplicate player"); } } emit RaffleEnter(newPlayers); } ```
The contest is live. Earn rewards by submitting a finding.
Submissions are being reviewed by our AI judge. Results will be available in a few minutes.
View all submissionsThe contest is complete and the rewards are being distributed.