# TWAPOracle might register with wrong token order

TWAPOracle.registerPair stored Uniswap cumulative prices assuming argument token order matched the pair's internal order, inverting prices when reversed.

- Payout: Audit contest
- Severity: high
- Program: Vader Protocol
- Found by: cmichel
- Disclosed: 2022-02-10
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2021-11-vader-findings/issues/171
- Library page: https://bugbountylibrary.com/r/c4%3A2021-11-vader%3AH-17
- 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.registerPair / update in Vader Protocol
**Root cause:** UniswapV2Factory.getPair ignores token order and returns the pair with its own internal token0/token1 ordering; the code assumed price0/1CumulativeLast matched the function argument order without checking pair.token0().
**Steps:**
1. Call `TWAPOracle.registerPair(factory, token0, token1)` with token0/token1 in an order opposite to the pair's internal ordering.
2. `IUniswapV2Factory(factory).getPair(token0, token1)` returns the same pair regardless of order.
3. Read `pair.price0CumulativeLast()` and `price1CumulativeLast()` which follow the pair's internal order.
4. Code pushes PairData with token0/token1 as arguments but cumulative prices in internal order, mismatched.
5. Same flaw in `update`.
**How found:** Code reading: noticed getPair ignores token order in Uniswap v2-core, then compared the stored cumulative price ordering against the argument ordering in the pushed PairData struct.
**Insight:** When integrating Uniswap v2 pairs, always reconcile your token ordering with pair.token0()/token1() before consuming price0/1CumulativeLast, since getPair is order-agnostic and returns internally-ordered data.