# Reserve does not properly apply prices of VADER and USDV tokens

VaderReserve multiplies IL by an oracle fixed-point price without rescaling, paying out 1e18x too much or too little IL protection.

- Payout: Audit contest
- Severity: high
- Program: Vader Protocol
- Found by: TomFrenchBlockchain
- Disclosed: 2022-05-03
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2021-12-vader-findings/issues/71
- Library page: https://bugbountylibrary.com/r/c4%3A2021-12-vader%3AH-08
- Tags: area:web3 domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:solidity technique:source-review vuln:accounting-error vuln:oracle-manipulation

**Target:** VaderReserve.sol IL protection payout logic
**Root cause:** Oracle returns VADER/USDV price as a fixed-point number (scaled 1e8/1e18) but Reserve multiplies IL by it without dividing by the scaling factor, so the reimbursement is off by 1e18.
**Steps:**
1. Read VaderReserve.sol lines 95-103 where IL is multiplied by LBT-returned USDV/VADER price.
2. Note oracle price is fixed-point scaled (1e8 or 1e18).
3. Observe no scaling factor applied to convert back to standard integer.
4. Trigger the else branch to make reserve pay out 1e18x too much IL protection.
**How found:** Code review of Reserve payout math comparing oracle fixed-point scaling against usage in USDV.sol reference implementation.
**Exploitation:** LP triggers IL protection claim hitting the else branch; reserve reimburses 1e18 times the correct amount, draining reserve funds.
**Insight:** When an oracle returns fixed-point prices, audit every multiplication site for a matching divide-by-scale; a missing rescale in one branch silently inflates payouts by the scale factor.