# Scaling factor of the wrapped token is incorrect

Notional's Boosted3Token leverage vault computed the wrapped token scaling factor from the main token's factor, corrupting collateral math and enabling over-borrowing or premature liquidation.

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

**Target:** Balancer Boosted3Token leverage vault mixin (Boosted3TokenPoolMixin.sol)
**Root cause:** _underlyingPoolContext multiplies the main token's scaling factor by the wrapped token rate instead of using the wrapped token's own decimal scaling factor, which LinearPool.getScalingFactors already returns correctly rate-adjusted.
**Steps:**
1. Read `_underlyingPoolContext` in `Boosted3TokenPoolMixin.sol` line 109.
2. Observe `wrappedScaleFactor = underlyingScalingFactors[mainIndex] * underlyingPool.getWrappedTokenRate() / BALANCER_PRECISION`.
3. Compare with Balancer `LinearPool.getScalingFactors`, which sets `scalingFactors[_wrappedIndex] = _scalingFactorWrappedToken.mulDown(_getWrappedTokenRate())`.
4. Note main and wrapped token decimals differ, so mainIndex factor is not a valid substitute.
5. Trace usage: scaled balances feed StableMath, then `convertStrategyToUnderlying` -> `VaultConfiguration.calculateCollateralRatio`.
6. Conclude collateral ratio is miscomputed, allowing over-borrow or premature liquidation.
**How found:** Code review comparing Notional's manual scaling-factor computation against Balancer's LinearPool reference implementation, spotting that getScalingFactors already applies the wrapped token rate and that main/wrapped decimal factors are not interchangeable.
**Exploitation:** No direct attack flow given; impact is via corrupted collateral ratio in the leverage vault, letting a user borrow beyond allowed limits or be liquidated early.
**Insight:** When integrating a protocol's view function, check whether it already applies a rate/derivative adjustment before re-applying it; and never substitute one token's decimal scaling factor for another's when decimals can differ.