# Incorrect valuation of vault share

WithdrawRequestBase valued split withdraw requests without adjusting for borrow/redeem token decimals, inflating collateral ~1e12x and letting attackers over-borrow.

- Payout: Contest reward
- Severity: high
- Program: Leveraged Vaults
- Credited: blackhole
- Disclosed: 2024-06-18
- Write-up quality: 7/10
- Original: https://github.com/sherlock-audit/2024-06-leveraged-vaults-judging/issues/60
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-06-leveraged-vaults%3AH-5
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:business-logic vuln:oracle-manipulation

**Target:** WithdrawRequestBase._getValueOfSplitFinalizedWithdrawRequest / TradingModule.getOraclePrice
**Root cause:** The valuation formula multiplies s.totalWithdraw (redeem token native decimals, e.g. 18) by the oracle rate (1e18) and divides only by EXCHANGE_RATE_PRECISION, never converting between redeem token and borrow token decimals, so the result stays in redeem-token precision instead of borrow-token precision.
**Steps:**
1. Set borrow token BT=6 decimals, redeem token RT=18 decimals, rate 10e18 (1 RT = 10 BT).
2. Claim s.totalWithdraw=100e18 RT across split with s.totalVaultShares=10e8, w.vaultShares=5e8.
3. Call _getValueOfSplitFinalizedWithdrawRequest: `(100e18 * 10e18 * 5e8) / (10e8 * 1e18)` = 5e20, interpreted as 500000000000000e6 BT instead of 500e6 BT.
4. Collateral is inflated ~1e12x; borrow against it and drain protocol assets.
**How found:** Code review of the valuation formula; noticed the oracle rate is normalized to 1e18 but the redeem token amount retains its native 18-decimal precision while the result is treated as borrow-token (6-decimal) units, then verified numerically with a worked example.
**Exploitation:** Attacker creates/finalizes a split withdraw request where borrow and redeem tokens have differing decimals, then uses the inflated collateral valuation to borrow far more than the real value and abscond with the borrowed funds.
**Insight:** When a value function mixes an oracle rate (fixed 1e18 precision) with a token amount, check that the token amount's native decimals are normalized to the output token's decimals; mismatched-decimal pairs (6 vs 18) expose missing precision scaling that same-decimal pairs hide.