DerivaDEX security record

Aave balances normally auto-increment through time with the accrued interest in the user's own balances. When Aave tokens are staked in the `InsuranceFund`, the staked value is saved at the moment of staking, the accrued interest will be still generated but for the total balance of the `InsuranceFund`, however the accrued interest for Aave tokens is calculated and divided when claiming later on. As an example, if we take a staking interval equal to 1 week, a user that stakes 1K aUSDT at day 1 will receive the same value of the accrued interest as a staker that stakes at day 7; the total accrued interest is equally divided between the users following their staking collateral at the end of the interval as implemented in `transferTokensAave()` function. Aave instantaneously divides all accrued interest between the stakers, meaning that if both stakers kept their collateral and didn't stake it, the initial user will gain more interest than if he staked in the insurance fund. A malicious user can stake a high amount of Aave tokens before the end of an interval to gain more interest, meaning that he can takes others stakers Aave accrued interest. The implemented logic to distribute Aave accrued interest is dependent on transaction ordering.

If during an upgrade `diamondCut()` is called multiple times, this situation can create issues since the fallback function does not pause, meaning that the users will be exposed to upgraded functions and old functions waiting to be upgraded at the same time.

DerivaDEX plans to list only USD stable coins, however all kind of tokens can be listed. The issue described below is applicable for both USD stable coins and other tokens (if listed). As implemented [here](https://github.com/apalepu23/derivadex_v1/blob/6bb9ac918e87bc416966b385cc5800cd7c310953/packages/protocol/contracts/facets/insurance-fund/InsuranceFund.sol#L541#L548), the sum of the user staked collaterals and the total staked collaterals sum is used to compute the interval DDX reward for the `msg.sender`. DDX reward is calculated following the underlying token unit in the case of compound or simply the aToken unit at the moment of staking for Aave or any other kind of tokens, The face value in USD of different stablecoins can drift from the target price, as an example if Token A face value is 1.05 USD and token B value is 0.95 USD, both stake will receive the same reward if the staked value is the same. Further, extra care should be used if tokens are added that contain a decimal value different than 18.

The function `addInsuranceFundCollateral()` allows the admin (governance) to admit new collateral types, which could be arbitrary tokens or contracts.

Using mappings with value types that require less than 32 bytes of storage will not save gas, instead, more gas will be required when the data is handled in memory. DDX token uses `uint96` as mapping value type for allowances and balances, this is adding extra complexity when implementing ERC20 standard functions, more gas consumption and non-compliance with the ERC20 standard. As an example using `safe96` inside `approve()` may cause function to revert for a reason not described in the standard; this can break some applications that interact with ERC20 tokens if they set any value between `uint96` and `uint256` (please not that `approve()` is intended to accept any value).

While new collateral types can be added, there is now way of removing an insurance fund collateral. If something goes wrong, it would stay in the contract forever, and could make loops over `collateralNames` more expensive.