# Incorrect Accrual Of sumNative and sumUSD In Producing Consultation Results

Vader's TwapOracle.consult summed native and USD prices separately before multiplying, producing incorrectly denominated oracle prices that feed protocol-sensitive actions.

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

**Target:** TwapOracle.consult() price oracle contract
**Root cause:** consult() sums native prices and USD prices across pairs separately then multiplies the sums, computing (Σp)(Σq) instead of Σ(p·q), yielding a mathematically wrong and misdenominated price.
**Steps:**
1. Read TwapOracle.sol consult() lines 115-157: loop over _pairs accumulating sumNative and sumUSD independently.
2. Observe final result = (sumUSD * decimals) / sumNative, i.e. (Σq·d)/(Σp).
3. With pairs SUSHI and UNISWAP: sumNative = USDV/SUSHI + USDV/UNISWAP, sumUSD = SUSHI/USD + UNISWAP/USD.
4. Compare to correct (SUSHI/USD·USDV/SUSHI + UNISWAP/USD·USDV/UNISWAP)/2; results differ.
5. Any consumer of consult() receives a false price.
**How found:** Manual code review of the oracle's aggregation math; recognized the algebraic mismatch between summing ratios separately versus summing products, analogous to (p1+p2)(q1+q2) ≠ p1q1+p2q2.
**Insight:** When an oracle aggregates multiple pairs, verify the math is Σ(priceUSD·priceNative)/n, not (ΣpriceUSD·d)/(ΣpriceNative); summing numerators and denominators separately silently misprices and can be exploited by skewing one pair.