> For the complete documentation index, see [llms.txt](https://zokyo-auditing-tutorials.gitbook.io/zokyo-tutorials/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://zokyo-auditing-tutorials.gitbook.io/zokyo-tutorials/tutorial-15-oracles/found-vulnerabilities-in-oracle-implementations/wrong-token-order-in-return-value.md).

# Wrong Token Order In Return Value

{% hint style="info" %}
[**Book an audit with Zokyo**](https://www.zokyo.io/)
{% endhint %}

## TWAPOracle might register with wrong token order 

#### Vulnerability Details

**Issue:**

The `TWAPOracle.registerPair` function is designed to take a `factory` and a pair of tokens (`token0`, `token1`). With the current setup, the function can accept any Uniswap-compatible `factory` as its argument. The issue arises when calling `IUniswapV2Factory(factory).getPair(token0, token1)`, as this does not guarantee the order of `token0` and `token1`; they might be reversed. This inconsistency in order affects the `price0CumulativeLast` and `price1CumulativeLast` values as well.

The code snippet below assumes that the internal order of `price0CumulativeLast` and `price1CumulativeLast` should match the order of function arguments `token0` and `token1`:

```javascript
javascriptCopy code_pairs.push(
    PairData({
        pair: pairAddr,
        token0: token0,
        token1: token1,
        price0CumulativeLast: price0CumulativeLast,
        price1CumulativeLast: price1CumulativeLast,
        blockTimestampLast: blockTimestampLast,
        price0Average: FixedPoint.uq112x112({_x: 0}),
        price1Average: FixedPoint.uq112x112({_x: 0})
    })
);
```

**Impact:**

This discrepancy can result in the oracle delivering inaccurate prices due to the potential inversion of the prices.

#### Recommended Mitigation Steps:

* **Internal Order Verification:** Validate if Uniswap's internal order of `token0` and `token1` matches the order provided as function arguments. If there is a mismatch, adjust the cumulative prices accordingly.

  Here's a pseudocode example for clarity:

  ```javascript
  javascriptCopy codeIUniswapV2Pair pair = IUniswapV2Pair(
      IUniswapV2Factory(factory).getPair(token0, token1)
  );
  pairAddr = address(pair);
  price0CumulativeLast = pair.price0CumulativeLast();
  price1CumulativeLast = pair.price1CumulativeLast();

  // Adjust cumulative prices based on token order
  (price0CumulativeLast, price1CumulativeLast) = (token0 == pair.token0()) ? 
      (price0CumulativeLast, price1CumulativeLast) : 
      (price1CumulativeLast, price0CumulativeLast);
  ```

  With this adjustment, the cumulative prices are set accurately, regardless of the order in which tokens are provided in function arguments.

## UniswapConfig getters return wrong token config if token config does not exist

#### Vulnerability Details

**Issue Description:**

The `UniswapConfig.getTokenConfigBySymbolHash` function is flawed due to a discrepancy in handling non-existent token configurations. The nested `getSymbolHashIndex` function returns `0` when there's no token configuration corresponding to the provided symbol hash (resulting from an uninitialized map value). However, the `getTokenConfigBySymbolHash` function incorrectly checks for non-existence using `-1`.

Similar issues occur with the following functions:

* `getTokenConfigByCToken`
* `getTokenConfigByUnderlying`

**Impact:**

This mismatch in non-existence checks leads the aforementioned functions to return the token configuration at the first index (index `0`), even when there's no valid configuration for the requested token. Since index `0` holds valid configuration data for a different token, this error causes the system to provide incorrect oracle prices for tokens. In severe cases, this malfunction can be exploited, allowing users to borrow tokens at inaccurately low prices or to inflate the collateral value erroneously. As a result, users might initiate undercollateralized loans that are impermeable to liquidation, posing a serious risk to the platform's financial stability.

#### Recommended Mitigation Steps:

* **Correct Non-Existence Check:**
  * Adjust the non-existence check in the `getTokenConfigBySymbolHash` function (and other similarly affected functions) to align with the value returned by `getSymbolHashIndex` for non-existent configurations (which is `0`).