QA Report - Githubissues

Please give more meaningful names to variables to ease the work of auditing:
```
IAddressProvider private _a;
```
Misleading variable name:
```
uint256 internal constant _MAX_INT = 2**256 - 1;
```
First, it is UINT, not INT, and second, it is not a max value, it is max - 1. There is a built-in keyword for a max value: type(uint256).max
DexSet is never emitted, probably an intention was to emit on setDexMapping:
```
event DexSet(uint8);
```

function _getNormalizedBalance in BalancerV2LPOracle should validate that decimals <= 18 or use SafeMath to prevent unexpected underflow here:

function _getNormalizedBalance(address token, uint256 balance) internal view returns (uint256) {
uint8 decimals = ERC20(token).decimals();
return balance.mul(MathPow.pow(10, 18 - decimals));
}

Constructor of the GUniLPOracle should also validate that here:

_tokenDecimalsOffsetA = 10**(18 - decimalsA);
_tokenDecimalsOffsetB = 10**(18 - decimalsB);

Do not cast explicitly without proper checks, better use SafeCast library to prevent unexpected results:
```
answer = int256(fairResA.mul(pxA).add(fairResB.mul(pxB)).div(pool.totalSupply()));
```
function claimMimo iterates over the _collateralCount which in theory is unbounded because it is incremented every time an owner calls depositAndBorrow or borrow with a new _collateralType. If the _collateralCount grows too large, it may lead to a denial of service when claimMimo cannot succeed due to the gas exceeding block limits. Make sure to prevent that, one possible solution is to have a reasonable limit for the maximum _collateralCount.
PARMinerV2 function liquidate does not validate that dexMapping is set, that is proxy and router addresses are not empty:
```
(address proxy, address router) = _dexAP.dexMapping(dexIndex);
collateralToken.approve(proxy, collateralToken.balanceOf(address(this)));
router.call(dexTxData);
```
It does not even check the return value and a low-level call succeeds if the address is empty or non-existent. dexMapping is a manually operated config so it may not contain info for all collateral tokens, and in such case, the collateral will remain in PARMinerV2 contract.
It is not clear why AdminInceptionVault and InceptionVaultFactory have a variable _weth, because it is not used in any meaningful way.
function _updateStake declares to return bool but actually does not return anything. Either remove the return declaration or return true/false as per intentions.
SafeMath is only meant to be used with uint256 type, using it with other types does not prevent overflows/underflows:
```
contract ChainlinkInceptionPriceFeed
using SafeMath for uint8;

oracleDecimals.add(collateralDecimals)
```
In this specific case, I did not find any serious issue with this, as you use it in a limited way but still you should at least know it and consider casting decimals to uint256 before adding them.
Careful with possible re-entrancy paths, e.g. in function releaseRewards, make sure you trust all the external contracts and tokens that you call. There are many places where Check-Effects-Interactions pattern is not followed opening gates for potential re-entrancy. Because this is a pretty well-known attack path I expect that you are aware of it and know how to protect from it.
Because depositToVault or depositAndBorrowFromVault accept any asset, it might be better to validate the balance before/after to know the actual amount transferred which may differ with deflationary or other weird tokens:
```
function depositToVault(address asset, uint256 amount) external {
...
token.transferFrom(msg.sender, address(this), amount);
...
}
```
Consider using the Safe ERC20 library and its safeApprove to handle approvals of tokens. But then do not forget to set approval to 0 before setting it to another value.

code-423n4 / 2022-04-mimo-findings

QA Report #137