LooksRare YOLO — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for LooksRare YOLO, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 4
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 4 closed, publicly disclosed LooksRare YOLO reports indexed on Coin Buggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, Reentrancy, across EVM-Solidity. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Logic error findings disclosed against LooksRare YOLO
- Reentrancy findings disclosed against LooksRare YOLO
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
LooksRare YOLO: Users can deposit "0" ether to any round
LooksRare YOLO, an on-chain lottery, let a user record zero-value ETH deposits into additional rounds through depositETHIntoMultipleRounds. Because winner selection relies on strictly ascending, non-repeating entry indexes, a zero deposit produces no index advance and must be forbidden, yet a depositAmount of 0 passes the modulo validation and adds nothing to expectedValue, so a caller can pad the amounts array with zeros at only gas cost. Each such entry occupies a bookkeeping slot with currentEntryIndex 0 that corrupts index bookkeeping and can make winner selection unfair. The issue was confirmed valid and rated High by the judge and fixed by reverting whenever depositAmount equals zero.
LooksRare YOLO: Rounds can not be immediately drawn after fulfillRandomWords due to VRF contracts reentrancy guard
LooksRare YOLO is a round-based on-chain lottery where each round's winner is selected by Chainlink VRF and the next round is started inside the VRF fulfillment callback. The reported flaw is a reentrancy-guard deadlock: when a future round is already full enough to be drawn immediately, the callback that concludes the current round (fulfillRandomWords) triggers an immediate nested requestRandomWords for the next round inside _startRound. Because Chainlink's VRFCoordinatorV2 sets its own nonReentrant lock before invoking the consumer contract, that nested request reverts, so the current round never concludes and no winner is ever declared, forcing governance to cancel the round. Sherlock's lead judge ruled this Medium and Unique despite the absence of direct fund loss, since the stuck round is cancellable but the mechanism would break the game each time the scenario recurs.
LooksRare YOLO: The number of deposits in a round can be larger than MAXIMUM_NUMBER_OF_DEPOSITS_PER_ROUND
LooksRare's YOLO lottery enforces a hard invariant that no round may exceed MAXIMUM_NUMBER_OF_DEPOSITS_PER_ROUND (100), but neither depositETHIntoMultipleRounds nor rolloverETH validates that cap. Because _startRound only auto-draws the next round when the protocol is unpaused, an admin pause during the VRF request-to-fulfillment window lets round 2 be opened without being drawn; once unpaused, users can deposit further into an already-full round and push its participant count past 100. This breaks an explicit game rule and skews draw odds, so the question was upheld as Medium despite an initial invalid challenge, with a fix adding a revert check in the shared _depositETH helper.
LooksRare YOLO: User can get free entries if the price of any whitelisted ERC20 token is greater than the round's `valuePerEntry`
LooksRare YOLO's deposit entrypoint whitelists the deposited token address but never checks that the declared token type (ERC20 vs ERC721) matches the actual asset being transferred. Because the transferFrom function signature is identical across both standards, a user can deposit an ERC20 while labeling it ERC721, causing the transfer manager to call transferFrom with a zero amount so nothing is actually paid. The entries are still credited using the cached price of that ERC20, so whenever a whitelisted ERC20's price exceeds the round's valuePerEntry (~$25), the user can mint arbitrary free entries via a batch of zero-valued token IDs, inflating the prize pool and forcing honest depositors to pay fees over value they can never claim.