RariCapital V2

Gas usage is a main concern for smart contract developers and users, since high gas costs may prevent users from wanting to use the smart contract. Even worse, some gas usage issues may prevent the contract from providing services entirely. For example, if a `for` loop requires too much gas to exit, then it may prevent the contract from functioning correctly entirely. The following instances have been found in the code base: 1. The nested `for`-loops inside `upgradeFundManager` could reach an out-of-gas error if the total number of pools for all currencies becomes large enough. This would prevent upgrades of `RariFundManager.sol`. 1. The nested `for`-loops inside `upgradeFundContoller` could reach an out-of-gas error if the total number of pools for all currencies becomes large enough. This would prevent upgrades of `RariFundController.sol`. 1. The loop inside `setFundManager` could reach an out-of-gas error if the number of supported currencies was too high. 1. The `withdrawAndExchange` function could reach an out-of-gas error if the number of `inputCurrenyCodes` was too high. 1. `getAllBalances` in `RariFundController` contains nested loops and a call to potentially expensive external functions inside the inner loop. 1. `marketSell0xOrdersFillOrKill` contains a loop with calls to to potentially expensive external functions and could reach an out-of-gas error if the number of orders was too high. 1. `checkLossRateLimit` contains a loop and could reach an out-of-gas error if the `_lossRateHistory` was too long. 1. `cachePoolBalances` contains nested loops and could reach an out-of-gas error if the number of supported currencies and number of pools was too high. 1. The loop inside `_withdrawFrom` could reach an out-of-gas error if the number of pools for a given currency code was too high. 1. The `exchangeAndDeposit` and the `withdrawAndExchange` functions in `RariFundProxy.sol` use `transfer()` instead of `call.value()` on L203 and L259, respectively. This might have issues when gas cost changes in the future. This has happened in the Istanbul hard fork, which increased the cost such that several existing smart contracts which were using `transfer()` broke due to out-of-gas errors. We anticipate that gas cost will continue to change in the future. 1. The `marketSell0xOrdersFillOrKill` function in `RariFundController.sol` uses `transfer()` instead of `call.value()` on L524. This might have issues when gas cost changes in the future. 1. The upgrade approach in `initNetDeposits()` might not be feasible if there are a significant number of users. Consider proxy storage approaches instead.

As it presently is constructed, the contract is vulnerable to the [allowance double-spend exploit](https://github.com/OpenZeppelin/openzeppelin-solidity/blob/b4f87bb8fc25fb07f73099701e39e167a3d36465/contracts/token/ERC20/ERC20.sol#L71-L78), as with other ERC20 tokens.

Until solidity `0.6.0`, the `ABIEncoderV2` feature is still technically in experimental state. Although there are no known security risks associated with it, these features should be used judiciously.

The following functions are missing validation of input arguments: 1. `upgradeFundController` does not validate the input parameter `newContract`, which could lead to sending all funds to any EOA. **Fixed** 1. `setFundManager` does not validate the input parameter `newContract`, which could lead to setting the fund manager to any EOA. 1. `setFundController` does not validate the input parameter `newContract`, which could lead to setting the fund controller to any EOA. 1. `authorizeFundManagerDataSource` does not validate the input parameter `authorizedFundManagerDataSource`, which could lead to setting a data source value of `0x0` for the fund manager. 1. `setFundToken` does not validate the input parameter `newContract`, which could lead to setting the token to any EOA. 1. `setFundProxy` does not validate the input parameter `newContract`, which could lead to setting the proxy to any EOA. 1. `setGsnTrustedSigner` does not validate the input parameter `newAddress`, which could lead to setting the fund manager to `0x0`. 1. `setInterestFeeRate()` should ensure that the rate is `<= 10**18`. **Fixed**

There is a recurring condition that appears in 6 methods inside the `RariFundToken` contract, namely: `if (address(rariGovernanceTokenDistributor) != address(0) && block.number > rariGovernanceTokenDistributor.distributionStartBlock())`, which appears in the following functions: `transfer`, `transferFrom`, `mint`, `burn`, `burnFrom`and ` fundManagerBurnFrom`. The second clause in the aforementioned condition is off-by-one, because it only allows claiming RGT one block after the distribution has started.