saffron.finance security record

`SaffronStakingV2.add()` allows adding more than once the same `LPToken`. This issue will dilute the user's rewards since `updatePool()` relies on `pool.lpToken.balanceOf(address(this))` to get the pool supposed balance, that will return the total value held by both pools (or more), which will dilute the user's rewards.

`set()` and `add()` functions members should always be executed with `massUpdatePools()` to avoid errors when computing the user's rewards since the total allocation points will change. However, both functions have a boolean (`_withUpdate`) input that will allow the owner or governance to modify the allocation point of a pool or to add a new pool with new allocation points without updating the accumulated reward per block for each pool. This can lead to distributing more or less reward than the amount expected.

The report gives no description here.

The report gives no description here.

The report gives no description here.

The report gives no description here.

The clone-and-own approach involves copying and adjusting open source code at one's own discretion. From the development perspective, it is initially beneficial as it reduces the amount of effort. However, from the security perspective, it involves some risks as the code may not follow the best practices, may contain a security vulnerability, or may include intentionally or unintentionally modified upstream libraries. Use Uniswap's `FullMath.sol` instead of `Math.sol` to avoid maintaining the code.

It is crucial to validate inputs, even if the inputs come from trusted addresses, to avoid human error. Following is the list of places that can potentially benefit from a stricter input validation: 1. `VaultFactory.addVaultType()` it is worth checking if that exact `bytecode` already exists. 2. `UniV3LimitedRangeAdapter.initialize()` does not validate `params.minTick` to be less than `params.maxTick`. 3. `VaultFactory.sol#154`: the `_adapterInfo.vaultAddress` of the `createVault()` function should be zero address. Otherwise, it is not possible to invoke `initializeVault()` if a vault is already attached to the specified `adapter`. 4. `VaultFactory.sol#162`: the `vaultAddress` of the `createVault()` function should not be zero. The assembly `create` function returns a zero address upon error. 5. `VaultFactory.sol#251`: the `adapterAddress` of the `createAdapter()` function should not be zero. The assembly `create` function returns a zero address upon error.

`UniV3LimitedRangeAdapter.removeLiquidity()` should require that earning have been settled. Safety checks must be implemented at the smart contract level to prevent future breaking changes. Similarly, `UniV3LimitedRangeAdapter.deployCapital()` should require that the token ID is not set in order to safely execute the transaction..

As security standards develop, so does the Solidity language. To stay up to date with current practices, it's important to use a recent version of Solidity and recent conventions.