OSIS security record

In the contract `Collection` the role `onlyOwner` has authority over the functions shown in the diagram below. Any compromise to the `onlyOwner` account may allow the hacker to take advantage of this. The malicious user could change the max amount of tokens to mint, and they could change the baseURI of the token. The base extension could also be changed destroying potentially destroying the IFPS hash. As well as pausing or unpausing the contract when they want to. The user could also drain all the assets sent to the contract.  ---- In the contract `MBGTokensV2` the role `BURNER_ROLE` has authority over the functions shown in the diagram below. Any compromise to the `BURNER_ROLE` account may allow the hacker to take advantage of this by calling the burn function to burn anyone's tokens.  In the contract `MBGTokensV2` the role `DEFAULT_ADMIN_ROLE` has authority over the functions shown in the diagram below. Any compromise to the `DEFAULT_ADMIN_ROLE` account may allow the hacker to take advantage of this. The malicious user could grant themselves the ability to burn or mint tokens. The malicious user would then call these functions to exploit the contract by granting themselves large quantities of tokens or burning from any user.  In the contract `MBGTokensV2` the role `MINTER_ROLE` has authority over the functions shown in the diagram below. Any compromise to the `MINTER_ROLE` account may allow the hacker to take advantage of this by minting any amount of tokens they want.  In the contract `MBGTokensV2` the role `controllers` has authority over the functions shown in the diagram below. Any compromise to the `controllers` account may allow the hacker to take advantage of this authority. This would allow an airdrop to any user by minting tokens to the user.  --- In the contract `Collection` the role `onlyOwner` has authority over the functions shown in the diagram below. Any compromise to the `onlyOwner` account may allow the hacker to take advantage of this. The malicious user could change the max amount of tokens to mint, and they could change the baseURI of the token. The base extension could also be changed destroying potentially destroying the IFPS hash. As well as pausing or unpausing the contract when they want to. The user could also drain all the assets sent to the contract.  --- In the contract `OSIS` the role `DEFAULT_ADMIN_ROLE` has authority over the functions shown in the diagram below. Any compromise to the `DEFAULT_ADMIN_ROLE` account may allow the hacker to take advantage of this. The deployer receives all the tokens on deployment. Along with being able to add and remove controllers.  ---- In the contract `MBStaking` the role `onlyOwner` has authority over the functions shown in the diagram below. Any compromise to the `onlyOwner` account may allow the hacker to take advantage of this and change the rewards. 

Functions that update state variables should emit relevant events as notifications.

The function `mint()` uses a loop to mint tokens to a certain address. This can loop to any number input.

It could be more efficient to have an approve all functionality for users to approve multiple at once.

The `SafeMath` library is used unnecessarily. With Solidity compiler versions 0.8.0 or newer, arithmetic operations will automatically revert in case of integer overflow or underflow. ```solidity=13 using SafeMath for uint256; ``` - `SafeMath` library is used for `uint256` type in `MBGTokensV2` contract.

Anyone can call this and create vaults. These functions are called when using `stake()` and `unstake()`. However, we are wondering the utility of these functions being public Additionally, multiple Vaults Can be Opened with Same ID.