Lines of code

https://github.com/code-423n4/2024-08-superposition/blob/4528c9d2dbe1550d2660dac903a8246076044905/pkg/seawater/src/lib.rs#L1013-L1017

Vulnerability details

Impact

Lesser liquidity in the pool for the particular token.

Proof of Concept

On Uniswap, there can be the same pool with multiple different fees, eg USDC-WETH 0.05%, USDC-WETH 0.3%.

The create_pool_D650_E2_D0() function takes in a non-fluid token address, calls init() on the pool.rs contract and sets the fee.

        self.pools
            .setter(pool)
>           .init(price, fee, tick_spacing, max_liquidity_per_tick)?;

For every token, there can only be one call to init().

  pub fn init(
        &mut self,
        price: U256,
        fee: u32,
        tick_spacing: u8,
        max_liquidity_per_tick: u128,
    ) -> Result<(), Revert> {
>       assert_eq_or!(
            self.sqrt_price.get(),
            U256::ZERO,
            Error::PoolAlreadyInitialised
        );

        self.sqrt_price.set(price);
        self.cur_tick
            .set(I32::lib(&tick_math::get_tick_at_sqrt_ratio(price)?));

Tokens can not have different fee tiers, which limits the liquidity provider and users.

Tools Used

Manual Review

Recommended Mitigation Steps

Not sure if the protocol intends for different fee tiers for the same token, but if so, set different fee tiers and allow the initialization of different fees for the same token by loosening the restriction of the check in init().

Assessed type

Uniswap

code-423n4 / 2024-08-superposition-validation

One token address cannot have different fee tiers #232