Read the findings of the 2022 Web3 Security Report

The `LABToken`(`LAB`) is a decentralized finance(DeFi) token deployed on BSC.\
The `LAB` transaction will include tax fee multiplied by the transaction amount when neither the sender nor the recipient is excluded from fees.\
The tax fees are including four parts as below: 
  * The Burning fee will be burned.
  * The Fund fee will be transferred to Fund address.
  * The LpHolder fee will be transferred to LpHolder address.
  * The LpPower fee will be transferred to LpPower address.
    
The owner can change these addresses above.

Financial Models

In the contract `BEP20` the role `_owner` has authority over the functions shown in the diagram below.
![](https://accelerator-tasks-prod.s3.amazonaws.com/4297108e87c84e838bf23a03db88f092/diagrams/centralization_BEP20__owner.svg)


In the contract `LABToken` the role `_owner` has authority over the functions shown in the diagram below.
![](https://accelerator-tasks-prod.s3.amazonaws.com/4297108e87c84e838bf23a03db88f092/diagrams/centralization_LABToken__owner.svg)


In the contract `Ownable` the role `_owner` has authority over the functions shown in the diagram below.
![](https://accelerator-tasks-prod.s3.amazonaws.com/4297108e87c84e838bf23a03db88f092/diagrams/centralization_Ownable__owner.svg)

Any compromise to the privileged account may allow the hacker to take advantage of this authority.

Centralization Risks in LABToken.sol

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

Initial Token Distribution

In the `setFees` function, there is no reasonable ceiling limit check for `taxFee` which may be assigned to arbitrary values.

Lack of Ceiling Limit of taxFee

SafeMath from OpenZeppelin is not used in function `_takeFees` which makes it possible for overflow/underflow and will lead to an inaccurate calculation result.\
In Line #283, the `tax` would be greater than `amount` if the `_taxFee` which has no upper boundary check is set to more than 100.\
In that situation, it will cause an underflow data issue to get a very large data in Line #290 under solidity version `v0.8.0`.

SafeMath Not Used

The function `_takeBurnFee` is used to burn specified `LAB` tokens, burning means decreasing the total supply.\
But in Line #267 and #317, the burned amount was added to the `recipient` address.\
Besides, the `Dead` address could be changed through function `setBurnAddr` by the owner.\
If it is changed to an available address, in this case, the burnFee is deduced from total supply, but transferred to the available address, there is an inconsistency here.

No Need Add Amount For Burning

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

File: LABToken.sol (Line 109, Contract `Ownable`)
```solidity
    function owner() public view returns (address) 
```


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


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


---
File: LABToken.sol (Line 172, Contract `BEP20`)
```solidity
    function totalSupply() public view override returns (uint) 
```


---
File: LABToken.sol (Line 176, Contract `BEP20`)
```solidity
    function balanceOf(address account) public view override returns (uint) 
```


---
File: LABToken.sol (Line 180, Contract `BEP20`)
```solidity
    function transfer(address recipient, uint amount)
```


---
File: LABToken.sol (Line 189, Contract `BEP20`)
```solidity
    function allowance(address towner, address spender)
```


---
File: LABToken.sol (Line 198, Contract `BEP20`)
```solidity
    function approve(address spender, uint amount)
```


---
File: LABToken.sol (Line 207, Contract `BEP20`)
```solidity
    function transferFrom(
        address sender,
        address recipient,
        uint amount
    )
```


---
File: LABToken.sol (Line 224, Contract `BEP20`)
```solidity
    function increaseAllowance(address spender, uint addedValue)
```


---
File: LABToken.sol (Line 236, Contract `BEP20`)
```solidity
    function decreaseAllowance(address spender, uint subtractedValue)
```


---
File: LABToken.sol (Line 428, Contract `BEP20Detailed`)
```solidity
    function name() public view returns (string memory) 
```


---
File: LABToken.sol (Line 432, Contract `BEP20Detailed`)
```solidity
    function symbol() public view returns (string memory) 
```


---
File: LABToken.sol (Line 436, Contract `BEP20Detailed`)
```solidity
    function decimals() public view returns (uint8) 
```


---
File: LABToken.sol (Line 449, Contract `LABToken`)
```solidity
    function takeOutTokenInCase(
        address _token,
        uint256 _amount,
        address _to
    )
```



Function Should Be Declared External

Literals with many digits are difficult to read and review.

File: LABToken.sol (Line 170, Function `LABToken.slitherConstructorVariables`)
```solidity
    address public Dead = 0x000000000000000000000000000000000000dEaD;
```


---
File: LABToken.sol (Line 443, Function `LABToken.constructor`)
```solidity
        _totalSupply = 400000000 * (10**18);
```



Too Many Digits

The approve function as built by both the ERC-20 and BEP-20 standard is inherently flawed in that it
provides a race-condition attack vector as defined in [SWC-114](https://swcregistry.io/docs/SWC-114).

BEP-20 Approve Race Condition

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

Missing Emit Events

The linked variables assigned in the constructor can be declared as `immutable`. Immutable state variables can be assigned during contract creation but will remain constant throughout the lifetime of a deployed contract. A big advantage of immutable variables is that reading them is significantly cheaper than reading from regular state variables since they will not be stored in storage.

Variables That Could Be Declared as Immutable

The function `takeOutTokenInCase` invocations do not check the return value of the function `transfer` which should yield a `true` result in case of a proper ERC-20 implementation.

```solidity=449
    function takeOutTokenInCase(
        address _token,
        uint256 _amount,
        address _to
    ) public onlyOwner {
        IBEP20(_token).transfer(_to, _amount);
    }
```

The aforementioned lines perform external calls function `transfer` of BEP20 contract and the return value is not checked in either case.

Unchecked Value of BEP-20 `transfer()` Call

BirdWorld

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

12

0

12

0

0