Uniswap pool might need a hop token to give the most accurate price
Summary
When oracle checks the price, it only checks a single pool with a single fee tier. However, pool might not be existed or it might be illiquid hence, it needs a hop token to get the price accurately.
Vulnerability Detail
Assume the swapper contract holds some ARB tokens, and the beneficiary of the swapper is LINK. The swapper will call the oracle to check if there is a pool between ARB-LINK; if not, it will revert. Currently, there are no pools for this pair. However, if someone were to swap ARB -> ETH -> LINK, that trade would be successful since ETH would be used as a hop token.
Similarly, assume the swapper has YFI and needs to convert it to LINK. Currently, the YFI-LINK pair has very low liquidity (1$). Such a trade would give a wrong price and could lead to problems.
Impact
This finding is somewhat similar to another finding I submitted. The aim of this separate finding is that it is mainly focused on obtaining the best prices rather than manipulation of low-liquidity pools. Therefore, I'll label this as medium.
Example:
When getting a quote of X respect to Y:
if X-Y pool has 500K liquidity and X-Z && Z-Y has 10M liquidity, best price quoted will be X -> Z -> Y rather than X -> Y directly
mstpr-brainbot
medium
Uniswap pool might need a hop token to give the most accurate price
Summary
When oracle checks the price, it only checks a single pool with a single fee tier. However, pool might not be existed or it might be illiquid hence, it needs a hop token to get the price accurately.
Vulnerability Detail
Assume the swapper contract holds some ARB tokens, and the beneficiary of the swapper is LINK. The swapper will call the oracle to check if there is a pool between ARB-LINK; if not, it will revert. Currently, there are no pools for this pair. However, if someone were to swap ARB -> ETH -> LINK, that trade would be successful since ETH would be used as a hop token.
Similarly, assume the swapper has YFI and needs to convert it to LINK. Currently, the YFI-LINK pair has very low liquidity (1$). Such a trade would give a wrong price and could lead to problems.
Impact
This finding is somewhat similar to another finding I submitted. The aim of this separate finding is that it is mainly focused on obtaining the best prices rather than manipulation of low-liquidity pools. Therefore, I'll label this as medium.
Example: When getting a quote of X respect to Y:
if X-Y pool has 500K liquidity and X-Z && Z-Y has 10M liquidity, best price quoted will be X -> Z -> Y rather than X -> Y directly
Code Snippet
https://github.com/sherlock-audit/2023-04-splits/blob/main/splits-oracle/src/UniV3OracleImpl.sol#L269-L282
Tool used
Manual Review
Recommendation
Allow oracle contract to have 2 modes or add another variable to PairOverride such that indicating whether to check directly X-Y pair or X-Z-Y.
The most popular pool pair is ETH, this can be used on Oracle level such as if the beneficiary token is something like YFI-LINK-AAVE-UNI
quote it as: base token -> ETH -> beneficiary token or base token -> beneficiary token
default path (x-z-y or x-y) can be determined when initializing the oracle and PairOverride can be used for specific cases.
Duplicate of #26