YieldFlow

Boolean constants can be used directly and do not need to be compared to true or false.

When transferring deflationary ERC20 tokens, the input amount may not be equal to the received amount due to the charged transaction fee. For example, if a user sends 100 deflationary tokens (with a 10% transaction fee), only 90 tokens actually arrived to the contract. However, a failure to discount such fees may allow the same user to withdraw 100 tokens from the contract, which causes the contract to lose 10 tokens in such a transaction. Reference: https://thoreum-finance.medium.com/what-exploit-happened-today-for-gocerberus-and-garuda-also-for-lokum-ybear-piggy-caramelswap-3943ee23a39f The contracts in scope are based on the `UniswapV3` mechanics which strictly do not support deflationary tokens.

The `require` statement below ```solidity=129 require(owner != address(0), "Owner cant be zero address"); .. .. owner = _owner; ``` is meant to check that the input variable `_owner` is not the zero address. However, the condition check is executed at line 129 while the `owner` variable is initialized at line 132. As a consequence the `require` will always trigger an error since it will check an uninitialized variable.

The following `require` statement ```solidity require(_token1 != address(0) || _token0 != address(0), "Zero address for tokens") ``` is meant to validate that the input addresses for `_token0` and `_token1` are both not zero addresses. However, due to the use of the logical OR `||` operator, this condition will pass even if only one of the tokens is the zero address. This means that the function will proceed even if one of the token addresses is not properly initialized, which may lead to unexpected behavior or potential issues later in the function execution.

The function `setEarnCooldownPeriod` allows setting the `earnCooldownPeriod` variable. When the users call the function `increaseLiquidity` the following line is executed: ```solidity=535 // users will only be considered for fees after earnCooldownPeriod userElement.earnTimestamp = block.timestamp + earnCooldownPeriod; ``` As a consequence, users will not receive fees until this period is over. Without enforcing a condition checking for a reasonable limit on this variable, the account with modification access can decide to set a really high limit preventing users from earning fees for their participation in the protocol. Additionally, there are no upper boundaries for the `fee` parameter in the function `changePositionParameter` which is used to change position parameters. Thus, it is possible to set a fee rate up to any arbitrary amount.

Addresses are not validated before assignment or external calls, potentially allowing the use of zero addresses and leading to unexpected behavior or vulnerabilities. For example, transferring tokens to a zero address can result in a permanent loss of those tokens. ```solidity=132 owner = _owner; ``` ```solidity=133 feeReceiver = _owner; ``` - `_owner` is not zero-checked before being used. --- ```solidity=147 yieldManager = _yieldManager; ``` - `_yieldManager` is not zero-checked before being used. --- ```solidity=916 owner = _newOwner; ``` - `_newOwner` is not zero-checked before being used. --- ```solidity=925 feeReceiver = _newFeeReceiver; ``` - `_newFeeReceiver` is not zero-checked before being used. --- ```solidity=939 token0 = _newToken0; ``` - `_newToken0` is not zero-checked before being used. --- ```solidity=940 token1 = _newToken1; ``` - `_newToken1` is not zero-checked before being used. --- ```solidity=950 yieldManager = _newYieldManager; ``` - `_newYieldManager` is not zero-checked before being used.

Performing division by zero would raise an error and revert the transaction. ```solidity=423 userElement.liquidity = userElement.liquidity * liquidity / totalLiquidity; ``` The expression `userElement.liquidity * liquidity / totalLiquidity` may divide by zero. Its divisor has has estimated interval [0, 340282366920938463463374607431768211455]. --- ```solidity=426 userElement.token0Balance += amount0Diff * userElement.liquidity / liquidity; ``` The expression `amount0Diff * userElement.liquidity / liquidity` may divide by zero. Its divisor has has estimated interval [0, 340282366920938463463374607431768211455]. --- ```solidity=429 userElement.token1Balance += amount1Diff * userElement.liquidity / liquidity; ``` The expression `amount1Diff * userElement.liquidity / liquidity` may divide by zero. Its divisor has has estimated interval [0, 340282366920938463463374607431768211455]. --- ```solidity=800 uint share0 = amount0 * userElement.liquidity / totalLiquidity; ``` The expression `amount0 * userElement.liquidity / totalLiquidity` may divide by zero. Its divisor has has estimated interval [0, 340282366920938463463374607431768211455]. --- ```solidity=801 uint share1 = amount1 * userElement.liquidity / totalLiquidity; ``` The expression `amount1 * userElement.liquidity / totalLiquidity` may divide by zero. Its divisor has has estimated interval [0, 340282366920938463463374607431768211455]. --- ```solidity=807 uint share0 = amount0 * userElement.liquidity / totalLiquidity; ``` The expression `amount0 * userElement.liquidity / totalLiquidity` may divide by zero. Its divisor has has estimated interval [0, 340282366920938463463374607431768211455]. --- ```solidity=808 uint share1 = amount1 * userElement.liquidity / totalLiquidity; ``` The expression `amount1 * userElement.liquidity / totalLiquidity` may divide by zero. Its divisor has has estimated interval [0, 340282366920938463463374607431768211455].

When a loop allows an arbitrary number of iterations or accesses state variables in its body, the function may run out of gas and revert the transaction. The highlighted locations contain a loop including the following line of code: ```solidity for (uint i = 0; i < userList.length; i++) { ``` Thus the loop body accesses the storage variable `userList`, whose length is not known at deployment time.

A reentrancy attack can occur when the contract creates a function that makes an external call to another untrusted contract before resolving any effects. If the attacker can control the untrusted contract, they can make a recursive call back to the original function, repeating interactions that would have otherwise not run after the external call resolved the effects. The `RangePositionManager` contract includes several external calls made in different functions like `collect`, `decreaseLiquidity`, `swap`, and `mint` that can potentially be manipulated by an attacker for a reentrancy attack in the case untrusted token contracts are used for the token pairs. Additionally, beyond untrusted contracts, in the case tokens with upgradeable contracts are used, they may be updated to an implementation allowing for reentrancy.

The highlighted functions allow setting new accounts, that are in charge of managing critical functionalities for the correct functioning of the protocol, without guaranteeing the designated accounts are able to actuate transactions on-chain.