Beans DAO - Audit

In the contract `BeansAuctionHouse` 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 set the auction property and pause/unpause the auction.  In the contract `BeansDescriptor` 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 set the Bean NFT properties.  In the contract `BeansToken` 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 set the token properties and the token minter.  In the contract `BeansToken` the role `beanteamDAO` has authority over the functions shown in the diagram below. Any compromise to the `beanteamDAO` account may allow the hacker to take advantage of this authority.  In the contract `BeansToken` the role `minter` has authority over the functions shown in the diagram below. Any compromise to the `minter` account may allow the hacker to take advantage of this authority and mint/burn the NFT token.  In the contract `OGBeansList` 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 add the `Og Bean` information.  In the contract `BeansDAOExecutor` the role `admin` has authority over the functions shown in the diagram below. Any compromise to the `admin` account may allow the hacker to take advantage of this authority and queue/cancel/execute transactions.  In the contract `BeansDAOExecutor` the role `pendingAdmin` has authority over the functions shown in the diagram below. Any compromise to the `pendingAdmin` account may allow the hacker to take advantage of this authority and accept transfer of admin rights.  In the contract `BeansDAOLogicV1` the role `admin` has authority over the functions shown in the diagram below. Any compromise to the `admin` account may allow the hacker to take advantage of this authority and set the voting properties.  In the contract `BeansDAOLogicV1` the role `pendingAdmin` has authority over the functions shown in the diagram below. Any compromise to the `pendingAdmin` account may allow the hacker to take advantage of this authority and accept transfer of admin rights.  In the contract `BeansDAOLogicV1` the role `vetoer` has authority over the functions shown in the diagram below. Any compromise to the `vetoer` account may allow the hacker to take advantage of this authority and veto any proposal.  In the contract `BeansDAOProxy` the role `admin` has authority over the functions shown in the diagram below. Any compromise to the `admin` account may allow the hacker to take advantage of this authority and upgrade the implementation contract. 

`BeansAuctionHouse` and `BeansDAOLogicV1` are upgradeable contracts, the owner/admin can upgrade the contract without the community's consensus. If an attacker compromises the account, he can change the implementation of the contract and drain tokens from the contract.

The following comments do not adequately describe the function/variable. ```solidity=36 // The Beans token URI descriptor IOGBeansList public ogBeansList; ``` ```solidity=285 /** * @notice Lock the seeder. * @dev This cannot be reversed and is only callable by the owner when not locked. */ function getSeed(uint256 beanId) external view onlyOwner returns (IBeansSeeder.Seed memory ){ return(seeds[beanId]); } ```

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

Unlike `BeansAuctionHouseProxy`, the `BeansDAOProxy` contract does not inherit the standard `TransparentUpgradeableProxy` contract (which inherits `ERC1967Proxy` that follows the EIP-1967 standard for storage slot management). This can be dangerous in future upgrades and can potentially cause storage slot collision. For example, if in a future upgrade the `BeansDAOProxyStorage` contract gets modified, either by changing, adding, or removing a variable, then there will be a mismatch in storage slot layout between the already deployed `BeansDAOProxy` contract, and the new implementation contract. This could cause unintended consequences for the project as a whole.

Weak PRNG due to a modulo on `block.timestamp`, `block.difficulty`, `msg.sender`, `block.coinbase`, `block.number`, `gasLeft` or `blockhash`. These can be predicted or influenced by miners to some extent, so they should be avoided. ```solidity=25 return(uint256(uint256(pseudorandomness >> randy) % itemCount)); ```