Carbon

In the contract `CarbonToken` the role `_owner` has authority over the functions shown in the diagram below.  Any compromise to the **_owner** account may allow a hacker to take advantage of this authority and do the following: - withdraw native tokens from the contract. - set fee contract. --- In the contract `CarbonTokenFee` the role `_owner` has authority over the functions shown in the diagram below.  Any compromise to the **_owner** account may allow a hacker to take advantage of this authority and do the following: - withdraw native tokens from the contract. - set fee rate, maximum value can be 100%. - set up addresses that requires pay fee. - set up a charging address. --- Since the contracts `Carbon` and `Fee` inherits from `Ownable` or `Ownable2Step`, the `_owner` role has authority over the functions below as well: - `renounceOwnership`: transfer ownership to address(0). - `transferOwnership`: transfer ownership to the new owner's address.

As per the `ERC20` standard, the `transferFrom()` function is utilized by a spender to transfer tokens from the token owner's account within the specified allowance. Nevertheless, the `Carbon` contract incorporates additional logic into the `transferFrom()` function. Specifically, if both `feeContract` and `masterAccount` are the zero address, the `transferFrom()` function will invoke `transfer()` and promptly return. This leads to an incorrect transfer, as the sender account is substituted with the `msg.sender` account rather than the `from` account. ```solidity function transferFrom( address from, address to, uint256 amount ) public virtual override returns (bool) { if (feeContract == address(0) || IFee(feeContract).masterAccount() == address(0)) { return super.transfer(to, amount); } ... } ```

All of the `CSIX` tokens are sent to the contract deployer or one or several externally-owned account (EOA) addresses. This is a centralization risk because the deployer or the owner(s) of the EOAs 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.

According to the design, the owner of the contract can withdraw all the native token in the contract. ```solidity function withdraw() public onlyOwner { uint256 balance = address(this).balance; payable(msg.sender).transfer(balance); } ``` However, the contract doesn't have a `receive()` function, so the contract can't accpet native tokens, which means that `withdraw()` function is meaningless.

Addresses are not validated before assignment or external calls, potentially allowing the use of zero addresses and leading to unexpected behavior or vulnerabilities. For example, transferring tokens to a zero address can result in a permanent loss of those tokens. - `_accounts` is not zero-checked before being used.

According to the design of `Carbon` token, when an address is added to the `feeAddressList`, if that address transfers tokens through `transfer()` or `transferFrom()` functions, the contract will deduct a 2.5% fee from the transaction amount (based on the initial setting), resulting in the recipient receiving a reduced amount. When the `CarbonTokenFee` contract is deployed, the contract will add `UniswapV3Router` related addresses to the `feeAddressList`. ```solidity constructor() { feeAddressList[0x68b3465833fb72A70ecDF485E0e4C7bD8665Fc45] = true; feeAddressList[0xE592427A0AEce92De3Edee1F18E0157C05861564] = true; } ``` Additionally, the owner of `feeContract` has authority to add/remove addresses to/from the `feeAddressList`. In theory, any address can be added to the list, including contract addresses. However, not all contracts are compatible with the features of the `Carbon` token. i.e some staking pools cannot support deflationary token. The scope of the audit treats third-party entities as black boxes and assumes their compatibility correctness.

The change of `_owner` by function `transferOwnership()` overrides the previously set `_owner` with the new one without guaranteeing the new `_owner` is able to actuate transactions on-chain.