Part 2

Zaros
PerpetualsDEXFoundrySolidity
70,000 USDC
View results
Submission Details
Severity: medium
Invalid

Static Fee Tier Configuration in `UniswapV3Adapter` Leads to Suboptimal Trade Execution

Summary

The UniswapV3Adapter contract implements a static, one-size-fits-all fee tier configuration for all Uniswap V3 trades, regardless of the token pair characteristics. This design limitation prevents the protocol from utilizing Uniswap V3's multiple fee tier feature, potentially resulting in suboptimal trade execution, higher costs for users, and inefficient liquidity utilization.

Vulnerability Details

The current implementation in UniswapV3Adapter.sol only allows for a single fee tier (either 0.05%, 0.3%, or 1%) to be set by the owner, which must then be used for all trades processed through the adapter.

uint24 public feeBps;
function setPoolFee(uint24 newFee) public onlyOwner {
// revert if the new fee is not 500, 3000 or 10_000
if (newFee != 500 && newFee != 3000 && newFee != 10_000) revert Errors.InvalidPoolFee();
feeBps = newFee;
emit LogSetPoolFee(newFee);
}

The issue is particularly visible in the executeSwapExactInput function where the swap path is fixed and provided in the swapPayload. There's no logic to check or optimize for liquidity across different fee tiers. The feeBps parameter is static and global for all trades.

This limitation becomes particularly problematic because different trading pairs have vastly different optimal fee tiers based on their volatility and trading characteristics.

For instance, stable pairs like USDC/USDT typically perform best with lower fees (0.05%), while more volatile pairs might require higher fees (0.3% or 1%) to compensate for increased impermanent loss risk.

Example Scenario:

Let's consider a real-world scenario to illustrate this issue:

Assume the UniswapV3Adapter's feeBps is set to 3000 (0.3%), and a user wants to execute two different trades:

Swapping 100,000 USDC to USDT
Current pool liquidity across fee tiers:

  • 0.05% pool: $10M liquidity, 1 pip spread

  • 0.3% pool: $2M liquidity, 3 pip spread
    Result: The trade is forced to use the 0.3% pool because of the static configuration, leading to:

  • Higher fees: Pays $300 in fees instead of$50

  • Worse price execution: Gets 99,670 USDT instead of 99,945 USDT

  • Total loss: $275 more than necessary

Impact

The adapter's inability to dynamically select the most liquid pool for each trade can result in increased slippage and suboptimal trade execution, particularly during periods of high market volatility.

Tools Used

Manual

Recommendations

To address these issues implement a dynamic fee tier selection system that can choose the optimal pool based on:

  1. Token pair characteristics (stable, regular, exotic)

  2. Current liquidity conditions

Updates

Lead Judging Commences

inallhonesty Lead Judge 10 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!