# Users may not be able to redeem their shares due to underflow

ggAVAX syncRewards before rewardsCycleEnd under-credits totalReleasedAssets, so redeemAVAX reverts on arithmetic underflow until cycle ends.

- Payout: Contest reward
- Severity: medium
- Program: GoGoPool
- Credited: 0xbepresent
- Disclosed: 2023-03-21
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-12-gogopool-findings/issues/317
- Library page: https://bugbountylibrary.com/r/c4%3A2022-12-gogopool%3AM-18
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:dos

**Target:** TokenggAVAX ERC4626 vault (syncRewards/redeemAVAX)
**Root cause:** syncRewards() called before rewardsCycleEnd sets lastRewardsAmt to only the elapsed portion, leaving totalReleasedAssets short of what previewRedeem computes for maxRedeem shares, causing subtraction underflow in redeemAVAX.
**Steps:**
1. Deposit AVAX via `ggAVAX.depositAVAX{value: 1200 ether}()`
2. Create minipool (2000 AVAX), recordStakingStart, skip duration
3. recordStakingEnd with 200 AVAX rewards
4. Call `ggAVAX.syncRewards()` before rewardsCycleEnd
5. skip 1 day; `ggAVAX.redeemAVAX(maxRedeem(bob))` reverts with arithmetic error
6. skip rewardsCycleLength+1 day, syncRewards again, redeem succeeds
**How found:** Code reading of syncRewards updating totalReleasedAssets/lastRewardsAmt versus redeemAVAX's asset accounting; Foundry PoC comparing maxRedeem vs previewRedeem after early sync.
**Exploitation:** No attacker profit; a ggAVAX holder calling redeemAVAX for maxRedeem shares after an early syncRewards hits underflow and cannot withdraw until the rewards cycle ends, temporarily locking funds.
**Insight:** In ERC4626-style vaults, compare maxRedeem() against previewRedeem() after partial reward syncs — mismatches between released-asset accounting and share price cause redeem underflow/lockups, especially early in vault life.