dForce

When updating the interest provider in `USR.updateInterestProvider` the inherited fee recipient from `Chargeable` is not updated. (The address might be the same, however, nothing guarantees it.) Please note that in `USR.initialize` the fee recipient address it taken from `IInterestProvider(_interestProvider).funds()` which is not done inside `updateInterestProvider` when updating the provider.

The check in lines 203-206 implemented in `migrateOldPool()` assumes the new contract does not hold any token balance, when tokens can be sent to the contract. The usage of such strict equality can deny access to that specific function.

Some functions make implicit assumptions that tokens remain constant in their supply during transactions. There exist tokens that add rewards or add fees, and hence their supply does not have to stay constant. We identified the following problematic pieces of code: * In `DFCollateral.sol`: line 18, * In `DFFunds.sol`: line 18, * In `DFPool.sol`: lines 23, 35, 47, 59, * In `DFPoolV2.sol`: lines 29, 41, 59, 77, 187, 203, * In `DFEngineV2.sol`: functions `deposit()` and `withdraw()`. Also the function `checkUSDXTotalAndColTotal()` in line 329; consequently all other operations that rely on it would fail.

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. It applies to the following: * `approve()`/`transferFrom()` in `Collaterals_t.sol`, and * `approve()`/`transferFrom()` in `DSTokenBase.sol`.

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.

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. It is best to break such loops into individual functions as possible.

There are no non-zero checks for arguments of type address in the following: * `DFPool.constructor()`, * `DFPoolV2.constructor()`, `DFPoolV2.initialize()`, `DFPoolV2.migrateOldPool()`, * `Collaterals_t.constructor()`, * `DSWrappedToken.constructor()`, * `DFSetting.constructor()`, * `DFProtocolView.constructor()`, * `DFEngine.constructor()`, * `InterestProvider.initialize()`, * `Chargeable.initialize()`, * `USR.initialize()`. Furthermore, `DFStore._setSection()` does not check that `_wrappedTokens` is a list of unique tokens.

The function `_setSection()` adds tokens. Malicious token may lead to a DoS attack. Similar observation applies to the function `withdrawInterest()`.

Smart contracts will often have `owner` variables to designate the person with special privileges to make modifications to the smart contract.

If the value of `minimalBurnAmount` is too large, it will prevent users from redeeming tokens.