Kochi Ken security record

In the `CKochiInvest` contract, the message of the below functions **must be signed** by the `CVerifySignature` contract's `signer`: - `createLaunchpad()`: create a launch pad, - `buy()`: buy a presale, - `claim()`: claim tokens, - `ownerClaim()`: owner claims tokens, - `ownerCancel()`: owner cancels a sale, - `setReferrer()`: set referrer. Users need to have the "verification" message signed by the signer before calling the aforementioned functions. The concern is, if the signer does not sign the message in time, users might not be able to buy tokens or claim tokens. In an extreme case, if the signer's private key is compromised or lost, all the tokens within the contract will be **lost forever**. In the contract `Kochi` 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.  * The pause() is removed in the new version of the contracts on 12/08/2022* In the contract `KochiInvest` 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. Furthermore, the function `terminate()` is a privileged function that can terminate presale prematurely and prevent the initiator of the presale from withdrawing the tokens.  In the contract `KochiLock` 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.  *The below description is based on the new version of the contracts on 12/08/2022* In the contract CKochi.sol the role `_owner` has authority over the functions shown below: - recoverERC20(), recovers tokens except the `KOCHI` tokens; - releaseAndLockLP(), releases and locks the LP tokens; - setLockContract(), set kochiLock. **[CertiK, 01/24/2023]** In the latest update, the function `payTaxes()` was divided into two functions, which are `payTaxes()` and `resolveTaxes()`, `resolveTaxes()` can only be executed by `owner`. However, the current design introduces another issue, namely the unguaranteed liquidity-adding process, meaning there is no guarantee for adding liquidity to the pool in time. Thus, it could lead to unexpected behaviors like token price fluctuation.

The contract `CBulksender`, `CKochiInvest`, `CKochiLock`, and `CKochiVest` 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.

```solidity= // add the liquidity router.addLiquidity( address(baseValueToken), address(this), tokenAmount, baseAmount, 0, // slippage is unavoidable 0, // slippage is unavoidable taxWallet, block.timestamp ); ``` The `_addLiquidity` function calls the `router.addLiquidity()` function with the `to` address specified as `taxWallet` for acquiring the generated LP tokens from the `KOCHI-USDT` pool. As a result, over time the `taxWallet` address will accumulate a significant portion of LP tokens. If the `taxWallet` is an EOA (Externally Owned Account), mishandling of its private key can have devastating consequences to the project as a whole.

All of the `Kochi` tokens are sent to the contract deployer when deploying the contract. This could be a centralization risk as the deployer can distribute tokens without obtaining the consensus of the community. ```solidity=48 _mint(msg.sender, supply); ```