Intended behavior:
Each participant should only be able to claim their reward once, and pot closure should execute atomically without external interference.
Issue:
The contract performs external token transfers in claimCut() and closePot() before fully locking state, without any reentrancy protection.
If the reward token implements transfer hooks (e.g., ERC777) or is a malicious ERC20, the token contract can reenter the Pot contract during transfer() and call claimCut() or closePot() again.
Because no reentrancy guard is present, state variables such as hasClaimed, remainingRewards, or pot closure state can be manipulated mid‑execution, allowing multiple reward claims.
Occurs when:
ERC777 tokens are used (standardized hooks)
Custom or malicious ERC20 tokens are used
Lower likelihood when using trusted ERC20s (USDC, DAI, WETH)
Multiple reward claims by a single attacker
Corrupted reward accounting
Unexpected repeated execution of claimCut() or closePot()
Direct loss of funds
High (H)
While likelihood depends on token choice, the impact is critical (fund theft).
Industry-standard audits rate this class of issue as High severity.
Add reentrancy protection to all functions performing external token transfers.
Prevents reentrant execution during token transfers
Enforces single-entry execution for reward distribution
Compatible with all ERC20 / ERC777 tokens
Industry‑standard mitigation
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.