Hardcoded Pool Selection in ZetaTokenConsumerTrident Contract

[c4-bot-8]

Lines of code

https://github.com/code-423n4/2023-11-zetachain/blob/main/repos/protocol-contracts/contracts/evm/tools/ZetaTokenConsumerTrident.strategy.sol#L88
https://github.com/code-423n4/2023-11-zetachain/blob/main/repos/protocol-contracts/contracts/evm/tools/ZetaTokenConsumerTrident.strategy.sol#L154

Vulnerability details

Impact

• Suboptimal Swaps: The contract employs a hardcoded pool selection mechanism that always chooses the first pool (pairPools[0]) when executing swaps. This rigid approach may lead to suboptimal swap rates and increased transaction costs for users. Suboptimal swaps result in users receiving fewer tokens than they should for the same input, significantly impacting their trading experience. Users may suffer financial losses due to the inefficiencies in the contract's token swap mechanism.

Proof of Concept

Consider the following:

• Alice calls the getZetaFromEth function providing the destination address and the minAmountOut she wants
• When performing the swap the function getZetaFromEth is getting ths list of pool by using this line

        address[] memory pairPools = poolFactory.getPools(token0, token1, 0, 1);

• The function will then always using the pool[0] when performing the swap.
• There could be multiple pool path for the swap, but the function is always choosing the first pool for the swap.

As the function is consistently selecting the first pool (pairPools[0]), it may not opt for the most liquid pool available. Consequently, this results in suboptimal swap rates for users, causing them to receive fewer ZetaTokens than they should have received for the same amount of ETH input.

Tools Used

Manual Review

Recommended Mitigation Steps

To address and mitigate the identified vulnerability, it is essential to make the contract's pool selection process dynamic, allowing it to choose the pool with the highest liquidity for each swap. Here are the recommended mitigation steps:

Dynamic Pool Selection: Modify the getZetaFromEth function to dynamically select the pool with the highest liquidity for the intended swap. Achieve this by iterating through the available pools and evaluating their liquidity.

// Modify the code snippet in getZetaFromEth function
uint256 maxLiquidity = 0;
address selectedPool;

for (uint256 i = 0; i < pairPools.length; i++) {
    uint256 liquidity = // Calculate the liquidity of the pool.

    if (liquidity > maxLiquidity) {
        maxLiquidity = liquidity;
        selectedPool = pairPools[i];
    }
}

IPoolRouter.ExactInputSingleParams memory params = IPoolRouter.ExactInputSingleParams({
    tokenIn: address(0),
    amountIn: msg.value,
    amountOutMinimum: minAmountOut,
    pool: selectedPool, // Use the selected pool with the highest liquidity
    to: destinationAddress,
    unwrap: false
});

Assessed type

Error

[DadeKuma]

QA might be more appropriate

[c4-pre-sort]

DadeKuma marked the issue as insufficient quality report

[c4-judge]

0xean marked the issue as unsatisfactory:
Overinflated severity

[Nabeel-javaid]

Hey, Really appreciate your review but I disagree with the decision.

https://solodit.xyz/issues/m-08-_swapuniswapv2-may-use-an-improper-path-which-can-cause-a-loss-of-the-majority-of-the-rewardtokens-code4rena-jpegd-jpegd-contest-git

https://solodit.xyz/issues/m-02-hardcoded-swap-path-might-not-be-the-most-optimalliquid-one-pashov-none-yield-ninja-markdown_

Above are the two issues that are very similar to what I've submitted. Due to the hard coding of Pool[0] if the pool is not the most liquid one then due to slippage user will receive very less Tokens but as the minOut is specified so the swap will revert cause DOS

[DadeKuma]

There isn't a loss of funds as there is slippage protection and users expect to get at least minAmountOut.

[0xean]

leaving as marked. This is equivalent to saying the contract should actually calculate the best multi transaction route also because a user would get a better rate. While true, it doesn't mean it qualifies as M

[0xean]

(final decision here)