Read the findings of the 2022 Web3 Security Report

The linked statements do not affect the functionality of the codebase and appear to be either leftovers from test code or older functionality.

Redundant Code Components

The functions which are never called internally within the contract should have external visibility for gas optimization.

File: CloudChatWallet.sol (Line 113, Contract `CloudChatWallet`)
```solidity
    function setBoss(address boss, bool online) public onlyOwner {
```


---
File: CloudChatWallet.sol (Line 132, Contract `CloudChatWallet`)
```solidity
    function setFinanceWallet(address wallet) public onlyOwner {
```


---
File: CloudChatWallet.sol (Line 140, Contract `CloudChatWallet`)
```solidity
    function setHotWallet(address wallet) public onlyOwner {
```


---
File: CloudChatWallet.sol (Line 147, Contract `CloudChatWallet`)
```solidity
    function submitTransferApply(address token, uint256 amount)
```


---
File: CloudChatWallet.sol (Line 176, Contract `CloudChatWallet`)
```solidity
    function cancelTransferApply(address token) public onlyFinance {
```


---
File: CloudChatWallet.sol (Line 222, Contract `CloudChatWallet`)
```solidity
    function tranferApprove(address token, bool isPass) public onlyBoss {
```


---
File: CloudChatWallet.sol (Line 91, Contract `CloudChatWallet`)
```solidity
    function deposit(
```


---
File: Ownable.sol (Line 28, Contract `Ownable`)
```solidity
    function renounceOwnership() public virtual onlyOwner {
```


---
File: Ownable.sol (Line 32, Contract `Ownable`)
```solidity
    function transferOwnership(address newOwner) public virtual onlyOwner {
```



Function Should Be Declared External

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

Missing Emit Events

In the contract `CloudChatWallet` 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 bring unpredictable damages to the project.
![](https://accelerator-tasks-prod.s3.amazonaws.com/b9441381d2044d7981563c4655d6aad4/diagrams/centralization_CloudChatWallet__owner.svg)

In the contract `CloudChatWallet` the role `bossData` has authority over the functions shown in the diagram below.
Any compromise to the `bossData` account may allow the hacker to take advantage of this authority and bring unpredictable damages to the project.
![](https://accelerator-tasks-prod.s3.amazonaws.com/b9441381d2044d7981563c4655d6aad4/diagrams/centralization_CloudChatWallet_bossData.svg)

In the contract `CloudChatWallet` the role `financeWallet` has authority over the functions shown in the diagram below.
Any compromise to the `financeWallet` account may allow the hacker to take advantage of this authority and bring unpredictable damages to the project.
![](https://accelerator-tasks-prod.s3.amazonaws.com/b9441381d2044d7981563c4655d6aad4/diagrams/centralization_CloudChatWallet_financeWallet.svg)

Centralization Risks in CloudChatWallet.sol

A reentrancy attack can occur when the contract creates a function that makes an external call to another untrusted contract before resolving any effects. If the attacker can control the untrusted contract, they can make a recursive call back to the original function, repeating interactions that would have otherwise not run after the external call resolved the effects.

### External call(s)
File: CloudChatWallet.sol (Line 238, Function `CloudChatWallet.tranferApprove`)
```solidity
            IERC20(token).transfer(hotWallet, amount);
```

### State variables written after the call(s)
File: CloudChatWallet.sol (Line 239, Function `CloudChatWallet.tranferApprove`)
```solidity
            resetApproveData(token);
```
* This function call executes the following assignment(s).
* In `CloudChatWallet.resetApproveData`,
    * `delete approveData[token]`

File: CloudChatWallet.sol (Line 239, Function `CloudChatWallet.tranferApprove`)
```solidity
            resetApproveData(token);
```
* This function call executes the following assignment(s).
* In `CloudChatWallet.resetApproveData`,
    * `delete bossPassedData[token]`


---
### External call(s)
File: CloudChatWallet.sol (Line 97, Function `CloudChatWallet.deposit`)
```solidity
        IERC20(token).transferFrom(msg.sender, address(this), amount);
```

### State variables written after the call(s)
File: CloudChatWallet.sol (Line 98-105, Function `CloudChatWallet.deposit`)
```solidity
        orders[id] = Order(
            id,
            msg.sender,
            token,
            amount,
            block.timestamp,
            true
        );
```



Potential Reentrancy Attack (Not Involving Ether)

The contract `CloudChatWallet` allows users to deposit to create an order with features id, from, token, amount, timestamp and exist. But the contract is a wallet that bosses can allocate the money inside the contract.

We would like to confirm with the client how the contract rewards users who deposit money in the contract.

Financial Models

Addresses should be checked before assignment or external call to make sure they are not zero addresses.

File: CloudChatWallet.sol (Line 133, Function `CloudChatWallet.setFinanceWallet`)
```solidity
        financeWallet = wallet;
```
- `wallet` is not zero-checked before being used.


---
File: CloudChatWallet.sol (Line 141, Function `CloudChatWallet.setHotWallet`)
```solidity
        hotWallet = wallet;
```
- `wallet` is not zero-checked before being used.



Missing Zero Address Validation

*This finding has a minor impact because the reentrancy only causes out-of-order events.*

A reentrancy attack can occur when the contract creates a function that makes an external call to another untrusted contract before resolving any effects. If the attacker can control the untrusted contract, they can make a recursive call back to the original function, repeating interactions that would have otherwise not run after the external call resolved the effects.

### External call(s)
File: CloudChatWallet.sol (Line 238, Function `CloudChatWallet.tranferApprove`)
```solidity
            IERC20(token).transfer(hotWallet, amount);
```

### Events emitted after the call(s)
File: CloudChatWallet.sol (Line 240, Function `CloudChatWallet.tranferApprove`)
```solidity
            emit TransferSuccess(token, hotWallet, amount);
```


---
### External call(s)
File: CloudChatWallet.sol (Line 97, Function `CloudChatWallet.deposit`)
```solidity
        IERC20(token).transferFrom(msg.sender, address(this), amount);
```

### Events emitted after the call(s)
File: CloudChatWallet.sol (Line 106, Function `CloudChatWallet.deposit`)
```solidity
        emit DepositSuccess(id, msg.sender, amount);
```



Potential Reentrancy Attack (Events)

The return value of the transfer()/transferFrom() call is not checked.

File: CloudChatWallet.sol (Line 238, Function `CloudChatWallet.tranferApprove`)
```solidity
            IERC20(token).transfer(hotWallet, amount);
```


---
File: CloudChatWallet.sol (Line 97, Function `CloudChatWallet.deposit`)
```solidity
        IERC20(token).transferFrom(msg.sender, address(this), amount);
```



Unchecked ERC-20 `transfer()`/`transferFrom()` Call

All of the `CloudChatToken` tokens are sent to the contract deployer when deploying the contract. This could be a centralization risk as the deployer can distribute all tokens without obtaining the consensus of the community.

Initial Token Distribution

The functions which are never called internally within the contract should have external visibility for gas optimization.

File: CloudChatToken.sol (Line 28, Contract `CloudChatToken`)
```solidity
    function name() public view virtual returns (string memory) {
```


---
File: CloudChatToken.sol (Line 32, Contract `CloudChatToken`)
```solidity
    function symbol() public view virtual returns (string memory) {
```


---
File: CloudChatToken.sol (Line 36, Contract `CloudChatToken`)
```solidity
    function decimals() public view virtual returns (uint8) {
```


---
File: CloudChatToken.sol (Line 40, Contract `CloudChatToken`)
```solidity
    function totalSupply() public view virtual returns (uint256) {
```


---
File: CloudChatToken.sol (Line 44, Contract `CloudChatToken`)
```solidity
    function balanceOf(address account) public view virtual returns (uint256) {
```


---
File: CloudChatToken.sol (Line 48, Contract `CloudChatToken`)
```solidity
    function transfer(address to, uint256 amount)
```


---
File: CloudChatToken.sol (Line 67, Contract `CloudChatToken`)
```solidity
    function approve(address spender, uint256 amount)
```


---
File: CloudChatToken.sol (Line 77, Contract `CloudChatToken`)
```solidity
    function transferFrom(
```


---
File: CloudChatToken.sol (Line 88, Contract `CloudChatToken`)
```solidity
    function increaseAllowance(address spender, uint256 addedValue)
```


---
File: CloudChatToken.sol (Line 98, Contract `CloudChatToken`)
```solidity
    function decreaseAllowance(address spender, uint256 subtractedValue)
```



State variables that never change should be declared as `constant` to save gas.

File: CloudChatToken.sol (Line 10, Contract `CloudChatToken`)
```solidity
    string private _name = "CloudChatToken";
```
- `_name` should be declared `constant`.


---
File: CloudChatToken.sol (Line 11, Contract `CloudChatToken`)
```solidity
    string private _symbol = "CC";
```
- `_symbol` should be declared `constant`.


---
File: CloudChatToken.sol (Line 12, Contract `CloudChatToken`)
```solidity
    uint8 private _decimals = 18;
```
- `_decimals` should be declared `constant`.


---
File: CloudChatToken.sol (Line 13, Contract `CloudChatToken`)
```solidity
    uint256 private _totalSupply = 100 * 10**9 * 10**18;
```
- `_totalSupply` should be declared `constant`.



State Variable Should Be Declared Constant

It can be checked that if `to == msg.sender` in the function `transfer()` to save gas.

Lack of input validation in function `transfer()`

It can be checked that if `spender == from` in the function `transferFrom()` to save gas.

Lack of input validation in function `transferFrom()`

In the contract `Ownable` 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 bring unpredictable damages to the project.
![](https://accelerator-tasks-prod.s3.amazonaws.com/b9441381d2044d7981563c4655d6aad4/diagrams/centralization_Ownable__owner.svg)

Centralization Risks in Ownable.sol

CloudChat

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

15

0

4

0

11