# DnGmxJuniorVaultManager#_totalAssets current implementation doesn't properly maximize or minimize

DnGmxJuniorVaultManager._totalAssets applied GLP price and slippage in the wrong direction, so maximize=true could return a lower NAV than minimize=false.

- Payout: Contest reward
- Severity: medium
- Program: Rage Trade
- Credited: 0x52
- Disclosed: 2022-10-28
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2022-10-rage-trade-judging/issues/36
- Library page: https://bugbountylibrary.com/r/sherlock%3A2022-10-rage-trade%3AM-6
- Tags: domain:web3 impact:integrity kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:oracle-manipulation

**Target:** DnGmxJuniorVaultManager._totalAssets NAV calculation
**Root cause:** The maximize flag was inverted when fetching GLP price for assets, and debt slippage was subtracted instead of added, so maximizing NAV minimized asset value and understated debt.
**Steps:**
1. Read `_totalAssets` in DnGmxJuniorVaultManager.sol#L1013-L1052
2. Observe `unhedgedGlp` uses `_getGlpPrice(state, !maximize)` so maximize=true picks the minimized price for assets
3. Observe `borrowValueGlp` slippage uses `MAX_BPS - slippageThresholdGmxBps`, reducing debt when minimizing
4. Conclude maximize=true can yield lower NAV than maximize=false
5. Fix: use `_getGlpPrice(state, maximize)` for assets and `MAX_BPS + slippage` for debt
**How found:** Code review of the maximize/minimize semantics: noticed the price direction was inverted for assets and slippage applied in the wrong direction for debt, contradicting the intended NAV bounds.
**Insight:** When a function takes a maximize/minimize flag, audit every price and slippage term for consistent direction: assets should use the best price and debt the worst when maximizing, and vice versa.