# MetaStable2TokenAuraVault allows only up to 1bp weight for Balancer TWAP oracle

MetaStable2TokenAuraVault caps Balancer TWAP oracle weight at 1bp due to wrong precision constant, so pricing relies almost entirely on Chainlink.

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

**Target:** MetaStable2TokenAuraVault oracle pricing (Balancer/Chainlink weighted average)
**Root cause:** initialize/setStrategyVaultSettings pass BalancerConstants.VAULT_PERCENT_BASIS (1e4) as the max balancerOracleWeight, but _getOraclePairPrice interprets weight against BALANCER_ORACLE_WEIGHT_PRECISION (1e8), so max weight is 1e4/1e8 = 1bp.
**Steps:**
1. Read MetaStable2TokenAuraVault.initialize: `BalancerVaultStorage.setStrategyVaultSettings(params.settings, MAX_ORACLE_QUERY_WINDOW, BalancerConstants.VAULT_PERCENT_BASIS)`
2. Note VAULT_PERCENT_BASIS = 1e4 while BALANCER_ORACLE_WEIGHT_PRECISION = 1e8
3. In _getOraclePairPrice, balancerWeightedPrice = balancerPrice * balancerOracleWeight and chainlinkWeightedPrice uses (1e8 - weight), then divides by 1e8
4. Conclude max Balancer share = 1e4/1e8 = 0.0001 (1bp); compare Boosted3TokenAuraVault which correctly sets weight 0
5. Impact: Chainlink errors/volatility pass ~fully into vault pricing, risking wrongful liquidations or blocked liquidations
**How found:** Code reading of vault initialization vs oracle weight math: noticed the limit constant (1e4) mismatched the weight precision (1e8) used in _getOraclePairPrice, and cross-checked against the 3-token vault that intentionally sets weight to 0.
**Insight:** When a config value is bounded by one precision constant but consumed against another, the effective cap is the ratio of the two — grep for mismatched *_PRECISION / *_BASIS constants at setter boundaries.