Read the findings of the 2022 Web3 Security Report

In the contract `CROCBOYBSC` 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/82c430931b5e4390a32d2532596195a9/diagrams/centralization_CROCBOYBSC__owner.svg)

In the contract `CROCBOYBSC` the roles in `isAuthorized` have authority over the functions listed below.

 - function `setTxLimit_max()`
 - function `setTxLimit_min()`
 - function `setMultipliers()`
 - function `manage_FeeExempt()`
 - function `manage_TxLimitExempt()`
 - function `manage_WalletLimitExempt()`

Any compromise to the accounts in `isAuthorized` may allow the hacker to take advantage of this authority.

Centralization Risks in CROCBOYBSC.sol

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

Initial Token Distribution

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

File: projects/CROCBOY/contracts/CROCBOYBSC.sol (Line 507, Function `CROCBOYBSC.setFeeReceivers`)
```solidity
autoLiquidityReceiver = _autoLiquidityReceiver;
```
- `_autoLiquidityReceiver` is not zero-checked before being used.


---
File: projects/CROCBOY/contracts/CROCBOYBSC.sol (Line 508, Function `CROCBOYBSC.setFeeReceivers`)
```solidity
marketingFeeReceiver = _marketingFeeReceiver;
```
- `_marketingFeeReceiver` is not zero-checked before being used.


---
File: projects/CROCBOY/contracts/CROCBOYBSC.sol (Line 509, Function `CROCBOYBSC.setFeeReceivers`)
```solidity
teamFeeReceiver = _teamFeeReceiver;
```
- `_teamFeeReceiver` is not zero-checked before being used.


---
File: projects/CROCBOY/contracts/CROCBOYBSC.sol (Line 510, Function `CROCBOYBSC.setFeeReceivers`)
```solidity
utilityFeeReceiver = _utilityFeeReceiver;
```
- `_utilityFeeReceiver` is not zero-checked before being used.


---
File: projects/CROCBOY/contracts/CROCBOYBSC.sol (Line 511, Function `CROCBOYBSC.setFeeReceivers`)
```solidity
devFeeReceiver = _devFeeReceiver;
```
- `_devFeeReceiver` is not zero-checked before being used.



Missing Zero Address Validation

The function call that sends Ether to an arbitrary address is unprotected.

File: projects/CROCBOY/contracts/CROCBOYBSC.sol (Line 423, Function `CROCBOYBSC.swapBack`)
```solidity
payable(marketingFeeReceiver).transfer(amountBNBMarketing);
```

File: projects/CROCBOY/contracts/CROCBOYBSC.sol (Line 424, Function `CROCBOYBSC.swapBack`)
```solidity
payable(teamFeeReceiver).transfer(amountBNBteam);
```

File: projects/CROCBOY/contracts/CROCBOYBSC.sol (Line 425, Function `CROCBOYBSC.swapBack`)
```solidity
payable(devFeeReceiver).transfer(amountBNBDev);
```



Sending Ether to Arbitrary Destinations

The return value of an external call is not stored in a local or state variable.

File: projects/CROCBOY/contracts/CROCBOYBSC.sol (Line 428-435, Function `CROCBOYBSC.swapBack`)
```solidity
router.addLiquidityETH{value: amountBNBLiquidity}(
  address(this),
  amountToLiquify,
  0,
  0,
  autoLiquidityReceiver,
  block.timestamp
);
```



Unused Return Value

The contract is serving as the underlying entity to interact with third party `PancakeSwap` protocol. 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

Pull-Over-Push Pattern

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.

Pull-Over-Push Pattern

The default value of the status variable `launchMode` is `true`. The owner can change it to `false` with the function `tradingStatus_launchmode()`. But it can never be changed to `true` again.

When the status variable `launchMode` is `false`, the following list of variables can no longer be changed.

- Once set to `false`, the variable `tradingOpen` can no longer be changed.
- Once set to `true`, the variable `blacklistMode` can no longer be changed.
- Once set to `true`, the variable `whitelistMode` can no longer be changed.
- Once an address has been added to the `isBlacklisted[]` mapping, it can no longer be removed.
- The `multiTransfer()` function can never be called by the owner.

The variable `launchMode` can only be changed once

A sandwich attack might happen when an attacker observes a transaction swapping tokens or adding liquidity without setting restrictions on slippage or minimum output amount. The attacker can manipulate the exchange rate by frontrunning (before the transaction being attacked) a transaction to purchase one of the assets and make profits by backrunning (after the transaction being attacked) a transaction to sell the asset.

The following functions are called without setting restrictions on slippage or minimum output amount, so transactions triggering these functions are vulnerable to sandwich attacks, especially when the input amount is large:

- `swapExactTokensForETHSupportingFeeOnTransferTokens()` (in function `swapBack()`, line #406)

Potential Sandwich Attacks

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

Missing Emit Events

The linked functions are equivalent to the compiler-generated getter functions for the respective variables.

User-Defined Getters

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 linked variables could be declared as `constant` since these state variables are never modified.

Variables That Could Be Declared as `constant`

State variables are inline initialized using either non-constant state variables or function calls that are not pure/constant. Since inline initialization occurs before the constructor call, some non-constant state variables may not be initialized and non-constant functions may behave in an unexpected way.

File: projects/CROCBOY/contracts/CROCBOYBSC.sol (Line 145, Contract `CROCBOYBSC`)
```solidity
uint256 public _maxTxAmount = _totalSupply * 2 / 1000;
```


---
File: projects/CROCBOY/contracts/CROCBOYBSC.sol (Line 147, Contract `CROCBOYBSC`)
```solidity
uint256 public _maxWalletToken = _totalSupply * 3 / 1000;
```


---
File: projects/CROCBOY/contracts/CROCBOYBSC.sol (Line 167, Contract `CROCBOYBSC`)
```solidity
uint256 public totalFee = marketingFee + liquidityFee + teamFee + utilityFee + devFee;
```


---
File: projects/CROCBOY/contracts/CROCBOYBSC.sol (Line 190, Contract `CROCBOYBSC`)
```solidity
uint256 public swapThreshold = _totalSupply * 10 / 10000;
```

Function Initializing State

File: projects/CROCBOY/contracts/CROCBOYBSC.sol (Line 456, Function `CROCBOYBSC.manage_whitelist`)
```solidity
for (uint256 i; i < addresses.length; ++i) {
```
- Local variable `i` is never initialized.

---
File: projects/CROCBOY/contracts/CROCBOYBSC.sol (Line 467, Function `CROCBOYBSC.manage_blacklist`)
```solidity
for (uint256 i; i < addresses.length; ++i) {
```
- Local variable `i` is never initialized.

---
File: projects/CROCBOY/contracts/CROCBOYBSC.sol (Line 474, Function `CROCBOYBSC.manage_FeeExempt`)
```solidity
for (uint256 i; i < addresses.length; ++i) {
```
- Local variable `i` is never initialized.

---
File: projects/CROCBOY/contracts/CROCBOYBSC.sol (Line 481, Function `CROCBOYBSC.manage_TxLimitExempt`)
```solidity
for (uint256 i; i < addresses.length; ++i) {
```
- Local variable `i` is never initialized.

---
File: projects/CROCBOY/contracts/CROCBOYBSC.sol (Line 488, Function `CROCBOYBSC.manage_WalletLimitExempt`)
```solidity
for (uint256 i; i < addresses.length; ++i) {
```
- Local variable `i` is never initialized.


Uninitialized Local Variable

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 differing compiler version numbers. 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 state variable is named as `targetLiquidityDenominator`, but it only used as a dividend in calculation.
```solidity=394
if(balanceOf(pair).mul(targetLiquidityDenominator).div(getCirculatingSupply()) > targetLiquidity ){
```

CROC BOY

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

17

0

13

0

4