Leaven Network - Audit

In the contract `LeavenVaultV6` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and modify contract parameters such as fees and strategies.  Furthermore, the role `_owner` has authority over the functions `transferOwnership()` and `renounceOwnership()`. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and modify the `_owner` address. 

In the contract `StrategyCakeBoostedLP`, the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and update several contract settings such as the fee recipient.  Furthermore, the role `_owner` has authority over the function `setBoostStaker()`. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and configure the `BoostStaker`. Additionally, the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and change the owner (`_owner` address) of the contract.  The role `keeper` has authority over the functions shown in the diagram below. Any compromise to the `keeper` account may allow the hacker to take advantage of this authority and pause or unpause the deposits and withdrawals and update other harvest parameters.  Furthermore, the role `keeper` has authority over the functions shown in the diagram below. Any compromise to the `keeper` account may allow the hacker to take advantage of this authority and update fee settings.  Additionally, the role `keeper` has authority over the function `setKeeper()`. Any compromise to the `keeper` account may allow the hacker to take advantage of this authority and update the `keeper` address. The role `strategist` has authority over the function `setStrategist()`. Any compromise to the `strategist` account may allow the hacker to take advantage of this authority and update the `strategist` address. Finally, the role `vault` has authority over the functions shown in the diagram below. Any compromise to the `vault` account may allow the hacker to take advantage of this authority and withdraw strategy funds. 

Performing integer division before multiplication truncates the low bits, losing the precision of calculation. ```solidity=1511 return _nativeBal.mul(45).div(1000).mul(callFee).div(MAX_FEE); ```

Hardcoded address may pose a centralization risk.

Contract code is missing natspec comments, which helps understand the code and all the function's parameters. It also increases code readability which is always welcomed. Together with the lack of documentation and unit tests, it makes the whole project difficult to review.

The `addLiquidity()` function converts half of a tokens to another token. The other half of tokens and part of the converted tokens are deposited into the `lpToken0-lpToken1` pool as liquidity. For every `addLiquidity()` function call, a small amount of tokens could be leftover in the contract. This is because the price of the token drops after swapping the first half of one token into the other, and the other half of token require less than the converted token to be paired with it when adding liquidity.

Addresses should be checked before assignment or external call to make sure they are not zero addresses.

It is highly recommended NOT to include OpenZeppelin library code directly in source code, but import the original library to minimize risk because even slight changes to the library code may lead to critical/major vulnerabilities/bugs. For Solidity version 0.6.x, the latest OpenZeppelin version 3.4.2 should be used.

A sandwich attack might happen when an attacker observes a transaction swapping tokens or adding liquidity without setting restrictions on slippage or minimum output amount. The attacker can manipulate the exchange rate by frontrunning (before the transaction being attacked) a transaction to purchase one of the assets and make profits by backrunning (after the transaction being attacked) a transaction to sell the asset. The `swapExactTokensForTokens()` function is called without setting restrictions on slippage or minimum output amount, so transactions triggering this function are vulnerable to sandwich attacks, especially when the input amount is large.

The change of `owner` by function `transferOwnership()` overrides the previously set `owner` with the new one without guaranteeing the new `owner` has the ability to actuate transactions on-chain. Furthermore, the `setKeeper()` and `setStrategist()` functions of the `StratManager` contract are also not requiring the new `keeper` or `strategist` addresses to accept the change.