# WAuraPools will irreversibly break if reward tokens are added to pool after deposit

WAuraPools stores per-token reward shares in a fixed array sized at mint; adding an Aura reward token later causes out-of-bounds revert, bricking pendingRewards and liquidations.

- Payout: Contest reward
- Severity: high
- Program: Blueberry
- Credited: 0x52
- Disclosed: 2023-04-07
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-04-blueberry-judging/issues/127
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-04-blueberry%3AH-7
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:high tech:solidity technique:source-review vuln:accounting-error vuln:dos

**Target:** WAuraPools wrapper contract (Aura reward accounting)
**Root cause:** accExtPerShare[tokenId] is a fixed-length array populated only for reward tokens existing at mint time, but extraRewardsLength() is read fresh each call, so a newly added extra reward token indexes past the array end.
**Steps:**
1. Deposit into WAuraPools to mint a position; accExtPerShare[tokenId] array is sized to current extraRewardsCount.
2. Aura adds a new extra reward token to the pool, increasing extraRewardsLength().
3. Call pendingRewards(tokenId) (invoked every tx via isLiquidatable in BlueberryBank#execute).
4. Loop reads `accExtPerShare[tokenId][i]` for the new index i, which is out of bounds and reverts.
**How found:** Code review of the reward loop: noticed extraRewardsLength() is fetched fresh while accExtPerShare is a fixed array written only at mint, implying a length mismatch when reward tokens are added.
**Escalation:** Because pendingRewards is called on every transaction through isLiquidatable, the revert bricks all interactions with affected positions, including liquidations.
**Insight:** When a contract snapshots a dynamic external list into a fixed array at creation but re-reads the live length later, any growth of the external list causes index mismatch; check reward-token/array accounting for such drift.