Internal accounting of vault balance may diverge from actual token balance in lending pool  Won't Fix
It is possible that the vault balance for a given bAsset is greater than the corresponding balance in the lending pool. This violates one of the correctness properties stated in the audit brief. Our Harvey fuzzer was able to generate a transaction that mints a small amount (0xf500) of mAsset. Due to the way that the lending pool integration (Compound in this case) updates the vault balance it ends up greater than the available balance in the lending pool.\\nMore specifically, the integration contract assumes that the amount deposited into the pool is equal to the amount received by the mAsset contract for the case where no transaction fees are charged for token transfers:\\n```\\nquantityDeposited = \\_amount;\\n\\nif(\\_isTokenFeeCharged) {\\n    // If we charge a fee, account for it\\n    uint256 prevBal = \\_checkBalance(cToken);\\n    require(cToken.mint(\\_amount) == 0, "cToken mint failed");\\n    uint256 newBal = \\_checkBalance(cToken);\\n    quantityDeposited = \\_min(quantityDeposited, newBal.sub(prevBal));\\n} else {\\n    // Else just execute the mint\\n    require(cToken.mint(\\_amount) == 0, "cToken mint failed");\\n}\\n\\nemit Deposit(\\_bAsset, address(cToken), quantityDeposited);\\n```\\n\\nFor illustration, consider the following scenario: assume your current balance in a lending pool is 0. When you deposit some amount X into the lending pool your balance after the deposit may be less than X (even if the underlying token does not charge transfer fees). One reason for this is rounding, but, in theory, a lending pool could also charge fees, etc.\\nThe vault balance is updated in function `Masset._mintTo` based on the amount returned by the integration.\\n```\\nbasketManager.increaseVaultBalance(bInfo.index, integrator, quantityDeposited);\\n```\\n\\n```\\nuint256 deposited = IPlatformIntegration(\\_integrator).deposit(\\_bAsset, quantityTransferred, \\_erc20TransferFeeCharged);\\n```\\n\\nThis violation of the correctness property is temporary since the vault balance is readjusted when interest is collected. However, the time frame of ca. 30 minutes between interest collections (may be longer if no continuous interest is distributed) means that it may be violated for substantial periods of time.\\n```\\nuint256 balance = IPlatformIntegration(integrations[i]).checkBalance(b.addr);\\nuint256 oldVaultBalance = b.vaultBalance;\\n\\n// accumulate interest (ratioed bAsset)\\nif(balance > oldVaultBalance && b.status == BassetStatus.Normal) {\\n    // Update balance\\n    basket.bassets[i].vaultBalance = balance;\\n```\\n\\nThe regular updates due to interest collection should ensure that the difference stays relatively small. However, note that the following scenarios is feasible: assuming there is 0 DAI in the basket, a user mints X mUSD by depositing X DAI. While the interest collection hasn't been triggered yet, the user tries to redeem X mUSD for DAI. This may fail since the amount of DAI in the lending pool is smaller than X.
It seems like this issue could be fixed by using the balance increase from the lending pool to update the vault balance (much like for the scenario where transfer fees are charged) instead of using the amount received.
```\\nquantityDeposited = \\_amount;\\n\\nif(\\_isTokenFeeCharged) {\\n    // If we charge a fee, account for it\\n    uint256 prevBal = \\_checkBalance(cToken);\\n    require(cToken.mint(\\_amount) == 0, "cToken mint failed");\\n    uint256 newBal = \\_checkBalance(cToken);\\n    quantityDeposited = \\_min(quantityDeposited, newBal.sub(prevBal));\\n} else {\\n    // Else just execute the mint\\n    require(cToken.mint(\\_amount) == 0, "cToken mint failed");\\n}\\n\\nemit Deposit(\\_bAsset, address(cToken), quantityDeposited);\\n```\\n