# Users redeem strategy tokens but receives no assets in return

Notional Balancer vaults burn strategy tokens but return zero assets when rounding makes bptClaim zero on small redemptions.

- Payout: Contest reward
- Severity: high
- Program: Notional
- Credited: xiaoming90
- Disclosed: 2022-12-20
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2022-12-notional-judging/issues/10
- Library page: https://bugbountylibrary.com/r/sherlock%3A2022-12-notional%3AH-8
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:precision-loss

**Target:** Balancer strategy vault redeem functions (TwoToken and Boosted3Token)
**Root cause:** Integer division in _convertStrategyTokensToBPTClaim truncates to zero when strategyTokenAmount * totalBPTHeld < totalStrategyTokenGlobal; _redeem returns 0 early instead of reverting, so tokens are burned with no assets returned.
**Steps:**
1. Call redeem with a small strategyTokens amount such that strategyTokens * totalBPTHeld / totalStrategyTokenGlobal == 0
2. Observe _convertStrategyTokensToBPTClaim returns bptClaim = 0
3. Observe _redeem hits `if (bptClaim == 0) return 0;` and exits without transferring assets
4. Confirm strategy tokens are burned/accounted while user receives nothing
**How found:** Manual code review of the conversion math, noting numerator/denominator precision mismatch (1e8 vs 1e18) and that the zero-result path returns instead of reverting.
**Exploitation:** User submits a redeem with a tiny strategy token amount; rounding yields zero bptClaim, the early return skips unstaking, and the user loses the burned tokens with no asset payout.
**Insight:** When auditing share-to-asset conversions, check every division for truncation-to-zero and whether the caller silently returns instead of reverting; compare against ERC4626/Solmate patterns that require nonzero assets.