Read the findings of the 2022 Web3 Security Report

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.

![](https://accelerator-tasks-prod.s3.amazonaws.com/882707a2685f41c08d0deeb50c701e0d/diagrams/centralization-Ownable-_owner.svg)

In the contract `STAR` 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.

![](https://accelerator-tasks-prod.s3.amazonaws.com/882707a2685f41c08d0deeb50c701e0d/diagrams/centralization-STAR-_owner.svg)

Centralization Risk

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

Initial Token Distribution

The method below can transfer any tokens of any amount to the `owner` role.
```solidity
function rescueToken(address tokenAddress, uint256 tokens)
    public
    onlyOwner
    returns (bool success)
{
    return IERC20(tokenAddress).transfer(msg.sender, tokens);
}
```
Any compromise to the `_owner` account may result in the loss of assets in the current contract.

Potential rug-pull privileged

```solidity=1032
IPancakeRouter(_router).addLiquidity(
  address(this),
  address(usdt),
  tokenAmount,
  uAmount,
  0,
  0,
  lpAddress,
  block.timestamp
);
```

The `addLiquidityUSDT` function calls the `IPancakeRouter(_router).addLiquidity` function with the `lpAddress` address for acquiring the generated LP tokens from the `STAR-USDT` pool. As a result, over time the `lpAddress` address will accumulate a significant portion of LP tokens. If the `lpAddress` is an EOA (Externally Owned Account), mishandling its private key can have devastating consequences for the project as a whole.

Centralization risk in `addLiquidity`

The linked statement should be `roundNodes[roundIndex].push(ref);`.

Logic issue in `_buyTransfer`

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

Missing Emit Events

The contract is serving as the underlying entity to interact with third-party `PancakeSwap` protocols. The scope of the audit treats 3rd party entities as black boxes and assume their functional correctness. However, in the real world, 3rd parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of 3rd parties can possibly create severe impacts, such as increasing fees of 3rd parties, migrating to new LP pools, etc.

Third party dependencies

Comparisons that are always true or always false may be incorrect or unnecessary.

```solidity
require(thres >= 0 && thres <= 100000000 * 10**18);
```
And the statement `thres >= 0` is always true.


Tautology or Contradiction

The linked variables could be declared as `constant` since these state variables are never modified.

Variables That Could Be Declared as `constant`

`public` functions that are never called by the contract could be declared `external`. When the inputs are arrays `external` functions are more efficient than public functions.

Improper Usage of `public` and `external` Type

The contract has unlocked compiler version. An unlocked compiler version in the source code of the contract permits the user to compile it at or above a particular version. This, in turn, leads to differences in the generated bytecode between compilations due to different compiler versions. This can lead to an ambiguity when debugging as compiler specific bugs may occur in the codebase that would be hard to identify over a span of multiple compiler versions rather than a specific one.

Unlocked Compiler Version

The **require** can be used to check for conditions and throw an exception if the condition is not met. It is better to provide a string message containing details about the error that will be passed back to the caller.

Missing Error Messages

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

Redundant Statements

In the following codes, we can find that the value of `roundIndex` may always be 0 if this condition `lastTime.add(3600) >= block.timestamp` is satisfied.

````solidity
if(amount >= thresTxAmount){
  if(lastTime != 0 && lastTime.add(3600) < block.timestamp){ 
    roundFirstAmounts[roundIndex] = _balances[address(FIRST)];
    roundNodeAmounts[roundIndex] = _balances[address(NODE)];
    roundLatestAmounts[roundIndex] = _balances[address(LATEST)];
    roundIndex++;
  }
  lastTime = block.timestamp
  ...
 }   
````

In this case, the recipient in `rounds[0]` will not get any reward. Is this the design intent?

STAR

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

14

0

14

0

0