# Earlier users in rollover queue can grief later users

In Y2K Carousel, a delisted queue user's slot is replaced by the last user, so processing past that index skips the last user's rollover mint.

- Payout: Contest reward
- Severity: high
- Program: Y2K
- Credited: BPZ
- Disclosed: 2023-03-06
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-03-Y2K-judging/issues/72
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-03-Y2K%3AH-2
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:high tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** Carousel.sol rollover queue / mintRollovers
**Root cause:** rolloverAccounting tracks a processed index per epoch, but delisting swaps the last queue item into the delisted slot; if the queue is processed past that index before the last user is minted, the swapped-in user is skipped.
**Steps:**
1. Alice enlists in rollover queue (index 1), Bob enlists (index 2)
2. Alice calls `mintRollovers(_operations=1)` so her funds roll over
3. Alice calls delist; Bob's queue item is moved into Alice's old index
4. Bob's rollover is never processed for this epoch until a new epoch is created or he delists and re-enlists
**How found:** Code reading of the delist swap-with-last logic combined with the per-epoch rolloverAccounting index; noticed the processed index can pass a relocated user's new position.
**Exploitation:** A user early in the queue processes their own rollover then delists, causing the last-enlisted user's slot to be relocated behind the processed index so their funds are not rolled over for that epoch.
**Insight:** When a queue uses swap-and-pop delisting plus a monotonic processed-index cursor, any item moved into an already-processed slot becomes unreachable for that epoch; check index-based cursors against mutable array positions.