# TwapOracle doesn't calculate VADER:USDV exchange rate correctly

TwapOracle used token decimals count (18) instead of 10**decimals as scaling factor, producing a wildly wrong VADER:USDV exchange rate feeding the minting mechanism.

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

**Target:** TwapOracle.sol exchange-rate calculation (Solidity contract)
**Root cause:** Line 156 multiplies sumUSD by IERC20Metadata(token).decimals() (the count, e.g. 18) instead of 10**decimals, so the result is off by ~17 orders of magnitude rather than properly scaled.
**Steps:**
1. Read TwapOracle.sol L156: `result = ((sumUSD * IERC20Metadata(token).decimals()) / sumNative);`
2. Observe for an 18-decimal token this becomes `(sumUSD * 18) / sumNative`
3. Compare to intended `(sumUSD * 10**decimals) / sumNative`
4. Note the resulting rate feeds Vader.sol minting logic
**How found:** Code review of the oracle's scaling math; the author noticed multiplying by the decimals count (18) rather than 10**decimals was 'plain weird' and traced the value into the minting mechanism.
**Insight:** When auditing oracle/price math, check every scaling term: multiplying by `decimals()` (a small count) instead of `10**decimals()` silently corrupts rates by orders of magnitude and is easy to miss in dense arithmetic.