UniswapV3Pool Manual Review Findings

UVP-01M: Improper Distribution of Rent Fees

Type	Severity	Location
Language Specific		UniswapV3Pool.sol:L486

Description:

A UniswapV3Pool::mint operation will distribute the fees required for a mint operation to the rentPayer before actually processing the liquidity mint operation, rendering the caller susceptible to arbitrage attacks by the rentPayer.

Impact:

Any UniswapV3Pool::mint operation would be fully susceptible to an arbitrage attack as part of the rent payment's distribution, compromising the integrity of the Uniswap V3-like pool.

Example:

Copy
473function mint(
474    address recipient,
475    int24 tickLower,
476    int24 tickUpper,
477    uint128 amount,
478    bytes calldata data
479) external payable override lock returns (uint256 amount0, uint256 amount1) {
480
481    {
482    uint256 requiredTinybars = HbarConversion.tinycentsToTinybars(IUniswapV3Factory(factory).mintFee());
483    if(msg.value < requiredTinybars){
484        revert MF();
485    }
486    IUniswapV3Factory(factory).rentPayer().call{value: msg.value}("");
487    }

Recommendation:

We advise the code to instead "credit" the rentPayer with the referenced balance, permitting them to invoke a special method to withdraw their "credit" from the UniswapV3Pool. This finding can be combined with the homonym one for UniswapV3Factory to accumulate all "credits" in the UniswapV3Factory instance rather than each pool individually, greatly optimizing the system.

Alleviation (5809242f0b533bd32b98253a971d07dd5a986bb1):

A "credit" system was put in place within the codebase by ensuring the msg.value of a UniswapV3Pool::mint call is equal-to-or-greater-than the requiredTinybars fee and permitting it to be extracted via the UniswapV3Pool::collectProtocol function that simply transmits the full native balance of the pool to the rentPayer referenced by the factory.

To note, this solution is possible because the UniswapV3Pool does not deal with native funds and instead solely handles tokens. As a result of this change, we consider this exhibit fully alleviated.

UVP-02M: Incorrect Code Adaptation

Type	Severity	Location
Mathematical Operations		UniswapV3Pool.sol:L372, L760

Description:

The referenced code segments invoked a special LiquidityMath::addDelta function in the original implementation of the codebase.

The new iterations are not identical to the originals; namely, they do not ensure that the subtracted value is non-zero (i.e. uint128(-params.liquidityDelta) / uint128(-liquidityNet)) and can also lead to underflows if either liquidityNet or params.liquidityDelta is equal to type(int128).min.

Impact:

A liquidity / state.liquidity that is equal to liquidityBefore / state.liquidity can cause significant misbehaviours in the exchange system's accounting if taken advantage of.

Example:

Copy
759state.liquidity = liquidityNet < 0
760    ? state.liquidity - uint128(-liquidityNet)
761    : state.liquidity + uint128(liquidityNet);

Recommendation:

We advise the code segments to imitate the original implementation, performing the params.liquidityDelta / liquidityNet negation in an unchecked code block and evaluating that the subtraction will yield a value less than the liquidityBefore / state.liquidity value.

Alleviation (3248d1d2fdfa6e1e270ff27db8eefb13dcb55c40):

The SaucerSwap team informed us that they specifically forked a specialized branch of the Uniswap V3 core repository and we validated that there were no changes performed in relation to the original within the code we considered susceptible.

As such, this exhibit is considered nullified.