Flayer — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Flayer, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 34
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 34 closed, publicly disclosed Flayer reports indexed on CoinBuggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, Oracle manipulation, Bridge exploit, Integer overflow / underflow, Front-running / MEV, 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 Flayer
- Oracle manipulation findings disclosed against Flayer
- Bridge exploit findings disclosed against Flayer
- Integer overflow / underflow findings disclosed against Flayer
- Front-running / MEV findings disclosed against Flayer
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Flayer: Malicious user can bypass execution of `CollectionShutdown` function
Flayer's CollectionShutdown module lets a locker manager permanently prevent a collection from being shut down, but the guard in preventShutdown only checks that shutdownVotes equals zero. Because start() increments shutdownVotes via _vote while reclaimVote() subtracts a caller's votes back down, a malicious user can call start then reclaimVote to leave shutdownVotes at zero, so the manager's preventShutdown transaction succeeds without ever recording its intent. This lets shutdown be re-initiated for a collection the manager believed was protected, defeating the veto mechanism's purpose.
Flayer: Price limit is used as the price range in internal swaps, causing swap TXs to revert
Flayer's UniswapImplementation computes internal pool swaps by calling SwapMath.computeSwapStep and passes the user-supplied sqrtPriceLimitX96 directly as the sqrtPriceTargetX96 parameter. In Uniswap V4, a price limit is the boundary at which a swap stops, whereas a price target is the input used to calculate in/out token amounts for each swap step; these are different concepts that must be translated via SwapMath.getSqrtPriceTarget. Because the internal swap uses the limit as the target, in/out token amounts are calculated against a wrong price, causing most swap transactions to unexpectedly revert. The finding was fixed by translating the price limit to a proper price range using SwapMath.getSqrtPriceTarget in the internal swap call. The impact is a DoS on swaps rather than fund loss, consistent with a medium-severity logic error.
Flayer: A user loses funds when he modifies only price of listings.
Flayer's Listings.modifyListings() lets an owner change only the floorMultiple (price) of a liquid listing while leaving duration untouched. When params.duration == 0, listing.created is not reset, yet the function still charges the full listing tax for the entire nominal duration via getListingTaxRequired() on line 355, whereas the refund computed in _resolveListingTax() only covers the remaining time from the original start. A user who merely re-prices a listing is therefore over-taxed on the already-elapsed portion of the original period. The fix is to reset listing.created to block.timestamp on every modification, not only when the duration changes.
Flayer: `reserve()` doesn't deletes the `_isLiquidation` mapping, causing tax loss for owner in future
Flayer's Listings contract sets an _isLiquidation flag on a tokenId when it is liquidated, but the reserve() function never clears that flag. A liquidation flag then persists even after a user reserves the token, withdraws it from ProtectedListings, and re-lists it on the open marketplace with prepaid tax. In _fillListing(), the lingering flag suppresses the _resolveListingTax call that would otherwise refund the unused prepaid tax, so the seller permanently loses that tax amount. The root cause is incomplete state cleanup that couples a liquidation lifecycle flag to an unrelated later listing.
Flayer: User can pay less protected listing fees.
In Flayer's ProtectedListings contract, unlockProtectedListing decrements the per-collection listingCount before calling _createCheckpoint, even though the checkpoint is computed from a utilization rate that depends on that listingCount. Because the decrement happens first, the recorded checkpoint is one listing lower than reality, so each subsequent unlock in the same collection is charged a smaller fee. The finding is demonstrated by a test in which the second token unlocks for a smaller amount than the first, producing a direct, scaling loss of fee revenue to the protocol.
Flayer: It is possible to prevent the execution of the `execute()` function, listing only one NFT.
Flayer's CollectionShutdown mechanism lets collection token holders vote to remove a collection from the platform, and once quorum is reached the contract owner can call execute() to delete it. That execute() path first checks _hasListing() and reverts if any NFT of the collection is currently listed in the Listings contract. Because anyone holding a single token of the collection can list it immediately after quorum is reached, a griefer can front-run the owner's execute() call and permanently block collection deletion. This makes the shutdown/governance mechanism unusable at trivial cost: a one-token listing permanently DoSes the deletion path. It is a genuine griefing and denial-of-service vulnerability rather than a fund-loss bug, judged medium severity.
All reports in this group
- Flayer: The health of a ```ProtectedListing``` is incorrectly calculated if the ```tokenTaken``` has be changed through ```ProtectedListings::adjustPosition()```.Logic error$0
- Flayer: Lister is overpaying during the cancel of his listing on ```Listings::cancelListings()```.Logic error$0
- Flayer: In the `Listings.sol#relist()` function, `listing.created` is not set to `block.timestamp`.Logic error$0
- Flayer: `ERC1155Bridgable` is not EIP-1155 compliantLogic error$0
- Flayer: Stale shutdown params can be reused to drain all funds from `CollectionShutdown` contractLogic error$0
- Flayer: Reserving a listing checkpoints the collection's `compoundFactor` at an intermediary higher compound factorLogic error$0
- Flayer: ````UniswapImplementation.beforeSwap()```` is vulnerable to price manipulation attackOracle manipulation$0
- Flayer: Owner Can Lose The Token After Being Unlocked but Not WithdrawnLogic error$0
- Flayer: Incorrect index handling in checkpoint creation leads to incorrect initial checkpoint retrieval and potential DoSLogic error$0
- Flayer: There is a logical error in the _distributeFees() function, resulting in an unfair distribution of fees.Logic error$0
- Flayer: If a collection has been shutdown but later re-initialized, it cannot be shutdown againLogic error$0
- Flayer: `ERC721Bridgable` and `ERC1155Bridgable` are not EIP-2981 compliant, and fail to correctly collect or attribute royalties to artistsBridge exploit$0
- Flayer: Frequency-dependent `TaxCalculator.sol::calculateCompoundedFactor` leads to interest loss either for users or for protocolLogic error$0
- Flayer: Admin can not set the pool fee since it is only set in memoryLogic error$0
- Flayer: Previous `beneficiary` will not be able to claim `beneficiaryFees` if current beneficiary is a poolLogic error$0
- Flayer: Quorum overflow in `CollectionShutdown` leads to complete drain of contract's fundsInteger overflow/underflow$0
- Flayer: The `relist` function does not check whether the listing is a liquidation listing causing users to pay taxes and refunds being paid to the listing owner who did not pay taxesLogic error$0
- Flayer: User can unlock protected listing without paying any fee.Logic error$0
- Flayer: Liquidity provided when initializing a collection in Locker.sol will be stuck in Uniswap, with no way for the user to recover itLogic error$0
- Flayer: FTokens are burned after `quorumVotes` are recorded making a portion of the shares unclaimableLogic error$0
- Flayer: Protected listings checkpoints are not always updated when the total supply changesLogic error$0
- Flayer: There is a logical error in the removeFeeExemption() function.Logic error$0
- Flayer: The attacker will prevent eligible users from claiming the liquidated balanceLogic error$0
- Flayer: The Users who voted for collection shutdown will lose their collection tokens by cancelling the shutdownLogic error$0
- Flayer: ERC1155Bridgable.sol cannot receive ETH royaltiesLogic error$0
- Flayer: `_listing` mapping not deleted when calling `Listings::reserve` can lead to a token being sold when it shouldn't be for saleLogic error$0
- Flayer: ERC1155 cannot claim royalities on L2.Logic error$0
- Flayer: Donation fees are sandwichable in one transactionFront-running / MEV$0