# Adversary can block NFT distribution on tiered bounties by assigning the NFTs to unused tiers

OpenQ tiered bounties let depositors specify arbitrary tier IDs for NFTs, filling all 5 NFT slots with unclaimable tiers and disabling NFT prizes.

- Payout: Contest reward
- Severity: medium
- Program: Openq
- Credited: 0x52
- Disclosed: 2023-01-30
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-02-openq-judging/issues/264
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-02-openq%3AM-3
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:access-control vuln:business-logic vuln:dos

**Target:** TieredBountyCore#receiveNft / DepositManagerV1#fundBountyNFT
**Root cause:** fundBountyNFT passes user-supplied _data to receiveNft, which decodes and stores an arbitrary _tier without validating it against the tierWinners length, so NFTs can be assigned to nonexistent tiers.
**Steps:**
1. Call `DepositManagerV1#fundBountyNFT` with `_data` encoding a tier ID far beyond the number of existing tiers (e.g. a huge uint).
2. `receiveNft` decodes `_tier` and stores the NFT under that unused tier.
3. Repeat until all five NFT deposit slots are consumed.
4. Legitimate tier winners can never claim these NFTs; setting a payout schedule for the huge tier would run out of gas.
**How found:** Code review of fundBountyNFT -> receiveNft flow noticing _data is user-controlled and _tier is stored without bounds check against tierWinners length.
**Exploitation:** Attacker funds the bounty with NFTs assigned to nonexistent/huge tier IDs, exhausting the five-NFT cap so no claimable NFT prizes can be added; large tier values make a matching payout schedule prohibitively gas-expensive.
**Insight:** When a deposit function decodes a user-supplied index/ID and stores it, check whether that index is validated against the array it will later be matched to; unvalidated IDs can occupy capped slots with unreachable entries.