# Settlement slippage is not implemented correctly which may lead to some vaults being impossible to settle

Boosted3TokenAuraHelper settlement ignores oracleSlippagePercent, capping slippage at balancerPoolSlippageLimitPercent (1%), making vault settlement impossible when slippage exceeds it.

- Payout: Contest reward
- Severity: high
- Program: Notional
- Credited: 0x52
- Disclosed: 2022-09-15
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2022-09-notional-judging/issues/42
- Library page: https://bugbountylibrary.com/r/sherlock%3A2022-09-notional%3AH-5
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:high tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** Boosted3TokenAuraHelper settlement logic in leveraged vaults
**Root cause:** _executeSettlement overwrites params.minPrimary from the TWAP and scales it only by balancerPoolSlippageLimitPercent, never applying the caller-supplied DynamicTradeParams.oracleSlippagePercent, so the per-settlement slippage setting has no effect.
**Steps:**
1. Read Boosted3TokenAuraHelper#_executeSettlement (L85-L113).
2. Observe params.minPrimary is set from _getTimeWeightedPrimaryBalance, discarding input.
3. Observe scaling uses only vaultSettings.balancerPoolSlippageLimitPercent / VAULT_PERCENT_BASIS.
4. Note oracleSlippagePercent from secondaryTradeParams is never decoded or applied.
5. Conclude max slippage is fixed at the pool constant (default 1%), so settlement reverts when real slippage exceeds it.
**How found:** Code review of the settlement path: noticed the function overwrites minPrimary from the oracle and only applies the pool-level slippage constant, while the dynamic oracleSlippagePercent parameter is validated upstream but never used in the calculation.
**Insight:** When a function takes a dynamic slippage/tolerance parameter, verify it is actually decoded and applied in the final min-out computation rather than silently replaced by a static config constant.