Vision Makers

In the contract `InvestmentPool`, the role `_projectfounder` has authority over the functions shown in the diagram below. Any compromise to the `_projectfounder` account may allow the hacker to take advantage of this authority and claim project funds after conditions are met.  In the contract `LinearVestingPool`, 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 revoke a stream from a wallet address, update stream status, add a new or update existing stream, and mark a stream as refunded. Note that the `InvestmentPool` contract is supposed to have this `_owner` role, but depending on the contract deployment process, this assumption is not always guaranteed.  In the contract `PoolManager`, 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 authority and update implementation addresses of the `InvestmentPool` and `LinearVestingPool` contracts, set pool manager role.  In the contract `PoolManager`, the role `MANAGER_ROLE` has authority over the functions shown in the diagram below. Any compromise to the `MANAGER_ROLE` account may allow the hacker to take advantage of this authority and rescue tokens to a specified recipient and amount, deploy new investment and vesting pools, change the token for a specific pool, set the platform fee receiver, set investment pool configuration, and set the platform fee receiver address. 

In the contract `PoolManager`, the role `DEFAULT_ADMIN_ROLE` has the authority to update the implementation contract behind the `InvestmentPool` and `LinearVestingPool` contracts. The `PoolManager` contract itself is also upgradeable and could sit behind a proxy contract. Any compromise to the `DEFAULT_ADMIN_ROLE` account or the account that can upgrade the `PoolManager` contract may allow a hacker to take advantage of this authority and change the implementation contract pointed by the proxy and execute potentially malicious transactions.

When transferring standard ERC20 deflationary tokens, the input amount may not be equal to the received amount due to the charged transaction fee. As a result, an inconsistency in the amount will occur and the transaction may fail due to the validation checks. The `InvestmentPool` contract implicitly assumes that the `paymentToken` is not a deflationary token.

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

Since Solidity Release 0.8.23, `MCOPY` opcode is introduced. However, this may not be compatible with all chains and L2s. As a result, the compatibility of the code could be affected.

The contract is serving as the underlying entity to interact with one or more third party protocols, and contain off chain components such as the construction of Merkle tree for token sale allocation. The tokens being sold/vested is also out of scope and its behavior and distribution is unknown to the auditor. The scope of the audit treats third party entities and off chain components as black boxes and assumes their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc.