# Oracle slippage rate is used for checking primary and secondary ratio

Notional's Curve pool ratio check reuses oraclePriceDeviationLimitPercent, so tuning oracle slippage can break reinvestReward's primary/secondary ratio validation.

- Payout: Contest reward
- Severity: medium
- Program: Notional
- Credited: xiaoming90
- Disclosed: 2023-02-27
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-02-notional-judging/issues/18
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-02-notional%3AM-3
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:dos vuln:misconfiguration

**Target:** Curve2TokenPoolUtils / StrategyUtils leveraged vault strategy
**Root cause:** _checkPrimarySecondaryRatio repurposes _checkPriceLimit (designed to compare spot vs oracle price) using oraclePriceDeviationLimitPercent to validate deposit ratio against pool balances, conflating two unrelated slippage tolerances.
**Steps:**
1. Read `_checkPriceLimit` in StrategyUtils.sol: bounds = oraclePrice ± oraclePriceDeviationLimitPercent.
2. Observe `_checkPrimarySecondaryRatio` in Curve2TokenPoolUtils.sol calls `_checkPriceLimit(expectedPrimaryPercentage, primaryPercentage)` and same for secondary.
3. Note the 'oraclePrice' arg is actually expected pool percentage, not an oracle price.
4. Changing oraclePriceDeviationLimitPercent to tune spot/oracle tolerance alters the ratio check bounds, potentially reverting `reinvestReward`.
**How found:** Code reading: noticed _checkPriceLimit, intended for spot-vs-oracle comparison, was reused in _checkPrimarySecondaryRatio where no oracle data is involved, flagging a semantic mismatch in the shared setting.
**Insight:** When a config parameter is reused across functions with different semantics, check whether tuning it for its intended purpose silently changes unrelated validation bounds — a common source of DoS via revert in reward/reinvest paths.