VaporNodes security record

In the contract `MasterChef` 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.  In the contract `MasterChef` the role `devaddr` has authority over the functions shown in the diagram below. Any compromise to the `devaddr` account may allow the hacker to take advantage of this authority. 

In the contract `Migrator` the role `chef` has authority over the functions shown in the diagram below. Any compromise to the `chef` account may allow the hacker to take advantage of this authority. 

In the contract `MoneyMaker` 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. 

In the contract `StableVapeStaking` 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. 

In the contract `VapeToken` 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. 

StableVapeStaking are upgradeable contracts, the owner can upgrade the contract without the community's commitment. If an attacker compromises the account, he can change the implementation of the contract and drain tokens from the contract.

When the same LP token is added into a pool more than once in function `add()`, the total amount of reward in function `updatePool()` will be incorrectly calculated. The current implementation is relying on the operation correctness to avoid repeatedly adding the same LP token to the pool, as the function will only be called by the owner.

`public` functions that are never called by the contract could be declared as `external`. `external` functions are more efficient than `public` functions.

When transferring standard ERC20 deflationary tokens, the input amount may not be equal to the received amount due to the charged transaction fee. For example, if a user stakes 100 deflationary tokens (with a 10% transaction fee) in a MasterChef, only 90 tokens actually arrived in the contract. However, the user can still withdraw 100 tokens from the contract, which causes the contract to lose 10 tokens in such a transaction. The MasterChef takes the pool token balance(the `lpSupply`) into account when calculating the users' reward. An attacker can repeat the process of deposit and withdraw to lower the token balance(`lpSupply`) in a deflationary token pool and cause the contract to increase the reward amount. Reference: https://thoreum-finance.medium.com/what-exploit-happened-today-for-gocerberus-and-garuda-also-for-lokum-ybear-piggy-caramelswap-3943ee23a39f

In the function `MasterChef.getMultiplier()`, the multiplier should be calculated by the following formula: ```solidity (number of blocks with bonus) * BONUS_MULTIPLIER + (number of blocks without bonus) ``` However, `startBlock`, which is set in L96, is not considered in the calculation. When the function is triggered by `MasterChef.pendingVape()` and `MasterChef.updatePool()`, the input variables `_from` and `_to` are always greater than `startBlock`, so it is unnecessary to consider `startBlock`. Given the `MasterChef.getMultiplier()` is a public function, which means it can be called externally, all possibilities of the input need to be fully considered. For example, if `_from < startBlock` and `_to < startBlock`, the multiplier should be `_from.sub(startBlock).mul(BONUS_MULTIPLIER)`, rather than `_to.sub(_from).mul(BONUS_MULTIPLIER)` which is calculated in the function.