Beincom - Audit 3

### BICVestingFactory In the contract `BICVestingFactory`, 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 create and initialize new redeem contracts with custom parameters.  ----- ### MultiSigner In the contract `MultiSigner`, 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 transfer ownership to an address they control, remove a signer, or add a signer.  ----- ### TokenSingletonPaymaster In the contract `TokenSingletonPaymaster`, 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 transfer ownership to an address they control, set the Oracle address to a malicious address, and add any address as a valid factory address.  ----- ### BicTokenPaymaster In the contract `BicTokenPaymaster`, 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 transfer ownership to an address they control, enable or disable pre-public status at any time, add or remove any address from the pre-public whitelist, set the pre-public rounds, set liquidity treasury address to receive LP tokens, block or unblock address status to prevent or allow an address to transfer tokens, set the liquidity fee limits, add or remove any address as a valid pool, change the LF period, the LF start time and the LF reduction value to interfere with the fee calculation, set swap back status and minimum swap back amount, grant or remove the privileged status `isExcluded` for multiple addresses, pause or unpause transfer for non-privileged addresses, withdraw any tokens and ETH to any address. 

The contract design allows the owner of `liquidityTreasury` address, to control the LP (liquidity provider) tokens. \ This centralized control creates a significant risk if the private keys of the privileged role are compromised, as an could remove the liquidity from the pool and withdraw the LP tokens. Such actions could severely impact users and the protocol’s stability, as liquidity removal often results in token price manipulation and loss of trust in the system.

All of the `BIC` tokens are sent to the `superController` address provided by the deployer. This is a centralization risk because the deployer can distribute tokens without obtaining the consensus of the community. Any compromise to these addresses may allow a hacker to steal and sell tokens on the market, resulting in severe damage to the project.

The `withdrawStuckToken()` function enables the owner to withdraw any tokens (including ETH when `token == address(0)`) stored in the contract and transfer them to any address. While this might be intended for operational flexibility, it creates a risk if their private keys are compromised. Specifically, an attacker could withdraw tokens intended for liquidity or other purposes, potentially harming users and the protocol's integrity.

The `TokenSingletonPaymaster` relies exclusively on a single oracle (`oracle`) for token exchange rates in `getTokenValueOfEth`, but it lacks key safeguards: - The contract never checks the oracle's operational status. - Oracle responses are never verified for correctness. - There is no alternative mechanism if the oracle fails or returns invalid data. This single dependency introduces a risk of denial of service, and potential data integrity vulnerabilities, where invalid or manipulated oracle data could be exploited to affect token valuations or operations.

The token allocation mechanism in the `BICVesting` contract uses percentages, which can lead to fairness issues due to rounding errors: 1. **Incomplete Allocations**: Allocations are not required to sum to 100%. Any remaining percentage is implicitly allocated to the final beneficiary, creating discrepancies between the expected and actual distributions. 2. **Rounding Discrepancies**: For small claimable amounts, rounding errors can result in zero distribution for all beneficiaries except the last one, who receives the entire claimable amount. Additionally to the fairness issue, this causes transparency issues as users reviewing allocations may not see accurate results due to the points above.