saffron.finance security record

When depositing fixed side liquidity in `deposit()` the function `deployCapital()` is invoked through `UniV3LimitedRangeAdapter` or `UniV3FullRangeAdapter`. In the `deployCapital()` function, the `amount0` and `amount1` required to provide `fixedSideCapacity` liquidity in Uniswap V3 are determined by `LiquidityAmounts.getAmountsForLiquidity()`. At `UniV3Vault.sol#77`, the fixed side depositor supplies `deployCapitalData` to `IUniV3Adapter.deployCapital()`. This data contains `amount0Min` and `amount1Min`, which determine the minimum amounts to be minted in the vault's position. However, allowing the fixed side depositor to set any value for these minimums may give them more control than advisable in determining the amount of each token deposited into the minted position. Therefore, the fixed side depositor may deposit amounts in either token that are substantially less than or greater than what was initially expected or intended. Allowing these minimums to be set to zero is also [described as a vulnerability in the Uniswap V3 documentation](https://docs.uniswap.org/contracts/v3/guides/providing-liquidity/mint-a-position#calling-mint).

Setter functions can emit duplicated events that may confuse external systems when the new value is equal to the old value: 1. `VaultFactory.setDefaultDepositTolerance()` 2. `VaultFactory.setFeeReceiver()` 3. `VaultFactory.setFeeBps()`

The `UniV3Vault.withdraw()` function allows variable side users to withdraw the profits made on the fixed side's deposit. It also allows the fixed bearer to withdraw their funds. However, earnings can be settled once and only once, and that is done when either the fixed bearer or a variable bearer makes the first withdrawal. If the party that makes the first withdrawal is a variable bearer, the fixed deposit will continue generating income until the fixed bearer withdraws, but the earnings are only determined at the time of the initial withdrawal and are not re-applied afterwards.

When a vault is created, if the fixed side reward is of high value, another user can front-run the vault creator and become the fixed side depositor, hence stealing opportunity from the vault creator. This will create a race condition where users will try to take a lucrative vault, even if the vault creator intended it for himself.

When a new vault is created and initialized, three `VaultBearerTokens` are created. The name and symbol of these tokens are the same across vaults: - `Saffron Vault Senior Bearer Token, "SAFF-BTS"` - `Saffron Vault Junior Bearer Token", "SAFF-BTJ"` - `Saffron Vault Senior Claim Token", "SAFF-CT"` This naming scheme can be confusing for users when exploring their assets in external services or applications (i.e. Metamask).

When smart contracts are deployed or their associated functions are invoked, the execution of these operations always consumes a certain quantity of gas, according to the amount of computation required to accomplish them. Modifying an unknown-size array that grows in size over time can result in a Denial of Service attack. Simply by having an excessively huge array, users can exceed the gas limit, therefore preventing the transaction from ever succeeding.

It is unclear how tokens are deposited to `SFIRewarder`. However, we recommend adding a dedicated function that calls `ERC20.transferFrom()` to avoid any address input error when handling the transfer.

The smart contract will use the `deposit()` function to send deposit assets from the user's account to the pool. When transferring ordinary ERC20 tokens, asset transfers work as expected, and the internal account balances are always consistent with the ERC20 token contract's real token balances. However, in the case of deflationary tokens, the input amount may differ from the returned amount due to the charges transaction fee, which can result in unexpected balance inconsistencies when comparing internal asset records to external ERC20 tokens contracts.

Enough `SFI` reward tokens need to be present in the `SFIRewarder` contract, otherwise, the reward payouts fail due to `safeSFITransfer` failing. As it is called on each claim (`deposit`, `withdraw`), users might not be able to claim their already allocated and pending rewards. Note that partial rewards are not paid out and the contract always tries to pay out the full rewards.