# `BalancerWeightedAuraVault.sol` wrongly assumes that all of the weighted pools uses `totalSupply`

BalancerWeightedAuraVault uses totalSupply() for BPT supply, but newer weighted pools require getActualSupply(), causing inaccurate share minting and LP valuation.

- Payout: Contest reward
- Severity: medium
- Program: Notional
- Credited: Vagner
- Disclosed: 2023-10-09
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-10-notional-judging/issues/36
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-10-notional%3AM-3
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:oracle-manipulation

**Target:** BalancerWeightedAuraVault.sol leveraged vault contract
**Root cause:** The vault hardcodes totalSupply() to read BPT supply, but newer weighted pools owe unminted protocol-fee BPT and expose getActualSupply() which adds that debt; totalSupply understates effective supply.
**Steps:**
1. Identify BalancerWeightedAuraVault uses `pool.totalSupply()` in `_calculateLPTokenValue` and `_mintVaultShares`.
2. Enumerate weighted pools using `getActualSupply` (e.g. 0x9f9d900462492d4c21e9523ca95a7cd86142f298, 0x3ff3a210e57cfe679d9ad1e9ba6453a716c56a2e, 0xcf7b51ce5755513d4be016b0e28d6edeffa1d52a).
3. Compare `totalSupply()` vs `getActualSupply()` on such a pool; the latter includes protocolFeesToBeMinted.
4. Observe vault share minting and LP token valuation diverge from true supply.
**How found:** Read Balancer docs on valuing BPT, noticed totalSupply is only valid for older pools, then checked newer weighted pools on-chain and confirmed they implement getActualSupply.
**Insight:** When integrating Balancer BPT, don't assume only composable stable pools use getActualSupply; verify per-pool via on-chain interface since newer weighted pools also pre-account protocol-fee debt.