# VaderReserve.reimburseImpermanentLoss improperly converts USDV to VADER

VaderReserve.reimburseImpermanentLoss divides USDV amount by usdvPrice instead of converting USDV→USD→VADER, paying out wrong VADER amount once a USDV price reading exists.

- Payout: Audit contest
- Severity: medium
- 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/7
- Library page: https://bugbountylibrary.com/r/c4%3A2021-12-vader%3AM-04
- Tags: area:web3 domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:accounting-error

**Target:** VaderReserve Solidity contract, reimburseImpermanentLoss
**Root cause:** The function treats usdvPrice (USD value of foreign assets / total USDV, i.e. inverse USDV price) as a USDV→VADER conversion rate, so it computes amount/usdvPrice rather than converting USDV to USD then to VADER.
**Steps:**
1. Read VaderReserve.sol L84-L110 reimburseImpermanentLoss.
2. Observe amount is denominated in USDV and usdvPrice is derived from foreign-asset USD value / total USDV supply.
3. Note the payout is computed as `amount / usdvPrice`, which is not a USDV→VADER conversion.
4. Once a single USDV price reading is stored, the reserve pays an incorrect VADER amount to recipient.
**How found:** Code review of the reserve's IL reimbursement math; noticed usdvPrice measures inverse USDV price, unrelated to VADER conversion, and that the if/else branches likely should both run (USDV→USD→VADER).
**Insight:** When a contract stores a 'price' variable, verify its units and direction (base/quote) against every use site; a value that is an inverse price or a ratio of reserves will silently mis-scale payouts when used as a conversion rate.