<username>{{ maskedUsername }}</username><space /><text>just voted for</text><space /><projectButton />

<username>{{ maskedUsername }}</username><space /><text>just voted for</text><space /><projectLogo /><space /><projectName>{{ projectName }}</projectName>

Bug Bounty rewards are grouped by severity and the impact of the vulnerability. Examples and descriptions of the type of vulnerabilities that correspond to each severity level can be found below. The payout amount has a 5 tier structure with separate scalesfor website/apps and smart contracts.

Description of vulnerability and your proof of concept or validation steps

Name

Please input a title

Short description of the vulnerability and the affected asset.

The core team is situated in country(ies) that received low aggregated ratings in terms of international judicial cooperation, criminal justice system, anti-money laundering, and corruption. This contextual data suggests an increased difficulty and complexity in preventing and mitigating fraud.

The core team is situated in country(ies) that received medium aggregated ratings in terms of international judicial cooperation, criminal justice system, anti-money laundering, and corruption. This contextual data suggests a medium level of geographic accountability, thus reducing and mitigating the risk of fraud.

The core team is situated in country(ies) that received the best aggregated ratings in terms of international judicial cooperation, criminal justice system, anti-money laundering, and corruption. This contextual data suggests the highest level of geographic accountability, thus maximizing the risk reduction and mitigation.

Vulnerability Title

transfer

transferFrom

totalSupply

balanceOf

allowance

approve

CryptoHuntersCoin

Based on our understanding, the reward token `CryptoHuntersCoin` provided by contracts `CryptoHuntersStaking` and `LPStaking` is the `CryptoHuntersCoin.sol` in this protocol.

According to the CryptoHuntersCoin.sol contract, the total number of tokens allocated for staking rewards is **270,000,000 ether**, and it will not mint a new token once the `CryptoHuntersCoin` contract is deployed.
```solidity=26
        supplyData["Staking"] = 270_000_000 * 10**decimals();
```

However, there is no validation check on this upper limit, it will allow these 2 staking pools to provide more than 270,000,000 ether rewards. As a result, users may not receive their rewards. In the worst-case scenario, the contract `CryptoHuntersStaking` may use up all the tokens allocated for rewards, leaving some users unable to withdraw their staked tokens.

Issues on Staking Reward

Performing integer division before multiplication truncates the low bits, losing the precision of calculation.

```solidity=165
        uint256 priceUSDT = (amount / 1000) * TOKEN_PRICE;
```


---
```solidity=192
            amountToClaim = (userStruct.tokensToIssue / 10_000) * CLAIM_PERCENT;
```


---
```solidity=165
        uint256 priceUSDT = (amount / 1000) * TOKEN_PRICE;
```


---
```solidity=192
            amountToClaim = (userStruct.tokensToIssue / 10_000) * CLAIM_PERCENT;
```


---
```solidity=168
        uint256 priceUSDT = (amount / 1000) * TOKEN_PRICE;
```


---
```solidity=195
            amountToClaim = (userStruct.tokensToIssue / 10_000) * CLAIM_PERCENT;
```


---
```solidity=221
        uint256 immediateAmount = (_amount / 10_000) * TGE;
```


---
```solidity=165
        uint256 priceUSDT = (amount / 1000) * TOKEN_PRICE;
```


---
```solidity=192
            amountToClaim = (userStruct.tokensToIssue / 10_000) * CLAIM_PERCENT;
```



Divide Before Multiply

```solidity=169
            paidCoinAddress = address(USDC);
```
- The variable `paidCoinAddress` is never used after this assignment.

---
```solidity=172
            paidCoinAddress = address(USDT);
```
- The variable `paidCoinAddress` is never used after this assignment.

---
```solidity=175
            paidCoinAddress = address(BUSD);
```
- The variable `paidCoinAddress` is never used after this assignment.

---
```solidity=169
            paidCoinAddress = address(USDC);
```
- The variable `paidCoinAddress` is never used after this assignment.

---
```solidity=172
            paidCoinAddress = address(USDT);
```
- The variable `paidCoinAddress` is never used after this assignment.

---
```solidity=175
            paidCoinAddress = address(BUSD);
```
- The variable `paidCoinAddress` is never used after this assignment.

---
```solidity=172
            paidCoinAddress = address(USDC);
```
- The variable `paidCoinAddress` is never used after this assignment.

---
```solidity=175
            paidCoinAddress = address(USDT);
```
- The variable `paidCoinAddress` is never used after this assignment.

---
```solidity=178
            paidCoinAddress = address(BUSD);
```
- The variable `paidCoinAddress` is never used after this assignment.

---
```solidity=169
            paidCoinAddress = address(USDC);
```
- The variable `paidCoinAddress` is never used after this assignment.

---
```solidity=172
            paidCoinAddress = address(USDT);
```
- The variable `paidCoinAddress` is never used after this assignment.

---
```solidity=175
            paidCoinAddress = address(BUSD);
```
- The variable `paidCoinAddress` is never used after this assignment.


Unused Value

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

```solidity=237
        coin.transfer(receiver, coin.balanceOf(address(this)));
```


---
```solidity=237
        coin.transfer(receiver, coin.balanceOf(address(this)));
```


---
```solidity=242
        coin.transfer(receiver, coin.balanceOf(address(this)));
```


---
```solidity=237
        coin.transfer(receiver, coin.balanceOf(address(this)));
```



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

The filed `PoolInfo.totalStaked` is not updated in the `emergencyWithdraw()` function.

Logical Issue in the `emergencyWithdraw()` Function

The `airdrop()` function allows the owner of the `CryptoHuntersCoin` contract to send any number of tokens from the `CryptoHuntersCoin` contract to any non-zero address.

Since there is no `external` or `public` function for minting new tokens, the maximum `_totalSupply` of the `CryptoHuntersCoin` token will be `2_500_000_000 ether`, this number is also the sum of tokens that should be sent to the supply proper contracts declared in the `SupplyData`.

|  Supply Name                |    Token Amount        |
|:--------------------------- | ----------------------:|
| "Pre Seed Sale"             |    65_000_000 * 10**18 |
| "Seed Sale"                 |   130_000_000 * 10**18 |
| "Private Sale"              |   190_000_000 * 10**18 |
| "Public Sale"               |    30_000_000 * 10**18 |
| "Staking"                   |   270_000_000 * 10**18 |
| "Project Team"              |   250_000_000 * 10**18 |
| "Game Reward Earning"       |   500_000_000 * 10**18 |
| "Liquidity & Market Making" |   120_000_000 * 10**18 |
| "Marketing & Development"   |   250_000_000 * 10**18 |
| "Community App Exchange"    |    25_000_000 * 10**18 |
| "Treasury"                  |   670_000_000 * 10**18 |
|                         SUM | 2_500_000_000 * 10**18 |

Therefore, once the owner executes the `airdrop()`, the `CryptoHuntersCoin` contract will not have enough tokens to send to the supply proper contracts.

Potentially not enough tokens for `airdrop`

When transferring deflationary ERC20 tokens, the input amount may not equal the received amount due to the charged transaction fee. For example, if a user sends 100 deflationary tokens (with a 10% transaction fee), only 90 tokens actually arrive at the contract. However, a failure to discount such fees may allow the same user to withdraw 100 tokens from the contract, which causes the contract to lose 10 tokens in such a transaction.

Reference:
https://thoreum-finance.medium.com/what-exploit-happened-today-for-gocerberus-and-garuda-also-for-lokum-ybear-piggy-caramelswap-3943ee23a39f

```solidity=273
        LPStakingCoin.safeTransferFrom(account, address(this), _amount);
```
- Transferring tokens by `_amount`.

```solidity=272
        pool.totalStaked += _amount;
```
- The `_amount` appears to be used for bookkeeping purposes without compensating the potential transfer fees.


---
```solidity=305
        LPStakingCoin.safeTransfer(account, _amount);
```
- Transferring tokens by `_amount`.

```solidity=304
        pool.totalStaked -= _amount;
```
- The `_amount` appears to be used for bookkeeping purposes without compensating the potential transfer fees.



Incompatibility with Deflationary Tokens

Since there is no validation for passed-in `_APR`, it will be able to set the `APR` of a pool to **ZERO**.

No Lower Limit for APR

### `require` statements for validating passed-in `_lockId`
```solidity
        require(_lockId >= 0 && _lockId <= 1, "Lock id required 0 or 1");
```
We recommend optimizing the condition with following example to improve the readability of the statements :
```solidity
        require(_lockId == 0 || _lockId == 1, "Lock id required 0 or 1");
```

---
### `require` statements for validating the unlock timestamp
In the `CryptoHuntersStaking` and `LPStaking` contracts, the `unstake()` function includes a `require` statement that prevents users from withdrawing locked tokens.

Specifically, the statement checks whether the current time is greater than or equal to the time when the tokens were staked plus the lockup period.
```solidity
        require(
            block.timestamp >= stakingData.joinTime + stakingData.lockTime,
            "CryptoHuntersStaking: still locked"
        );
```
However, if the lockup period extends beyond the pool's end time, users may be unable to withdraw locked tokens even after the pool has stopped, resulting in no further rewards.

We would like to discuss whether it would be more reasonable to allow users to withdraw tokens from pools that have already stopped.

Unreasonable  Conditions of `require` Statements

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

Missing Emit Events

```solidity=14
    using SafeCast for uint256;
```
- The library `SafeCast` is declared on a using-for directive in `CryptoHuntersStaking` but its functionalities are never used.


---
```solidity=15
    using EnumerableSet for EnumerableSet.UintSet;
```
- The library `EnumerableSet` is declared on a using-for directive in `CryptoHuntersStaking` but its functionalities are never used.


---
```solidity=14
    using SafeCast for uint256;
```
- The library `SafeCast` is declared on a using-for directive in `LPStaking` but its functionalities are never used.


---
```solidity=15
    using EnumerableSet for EnumerableSet.UintSet;
```
- The library `EnumerableSet` is declared on a using-for directive in `LPStaking` but its functionalities are never used.



Unused Contract

```solidity=47
    event PendingWithdraw(
        uint256 indexed poolId,
        address indexed account,
        uint256 amount
    );
```
- `PendingWithdraw` is declared in `CryptoHuntersStaking` but never emitted.


---
```solidity=50
    event PendingWithdraw(
        uint256 indexed poolId,
        address indexed account,
        uint256 amount
    );
```
- `PendingWithdraw` is declared in `LPStaking` but never emitted.



Unused Event

The comments at the linked positions are inconsistent with the codes.

Inconsistent Comment and Code

The following fields at the linked positions are declared in the `User` struct but never used.
- uint256 liquidBalance
- bool isLocked
- uint256 initialPayout
- bool hasBought

Unused Fields in The `User` Struct

Reference: https://crypto-hunters.tv/documents/CH-PITCH-PRESENTATION_3-20-23.pdf, page 14.

We have found inconsistencies between implementing some parts of the Crypto Hunters Coin Sale and the promotional content on the official website.

1. The implementation of the sale price is not consistent:
     - Pre-Seed Sale: **$0.2** in pdf but **0.02 usd** in `PreSeedSale.sol`
     - Seed Sale: **$0.25** in pdf but **0.025 usd** in `Seed.sol`
     - Private Sale: **$0.39** in pdf but **0.039 usd** in `Private.sol`
     - Public Sale: **$0.45** in pdf but **0.045 usd** in `Public.sol`
  
2. The implementation of the CLIFF of Public Sale is not consistent:
   - CLIFF is **8 months** in the PDF but **60 days** in `Public.sol`

Explanation About Coin Sale

In both of the 4 sale phases, sale contracts allow users to purchase the `Crypto Hunters Coin` multiple times, and it may cause some issues :
1. Every time a user makes a purchase, the lock-up period is reset, forcing them to wait from the beginning again.
2. The field `User.tokensToIssue` restricts users from unlocking a portion of the amount from the latest purchase, instead of the entire brought amount.

Since there is an unused filed `User.hasBought`, we think a user may be allowed to buy only once in each sale phase.

Explanation About Buying Token

Crypto Hunters

CryptoHuntersCoin.sol

CryptoHuntersStaking.sol

LPStaking.sol

PreSeedSale.sol

PrivateSale.sol

PublicSale.sol

SeedSales.sol

Formal Verification

The Crypto Hunters TV Show is the first-ever adventure-reality TV show and mobile AR game focused on cryptocurrency.

Leaderboards

Due Diligence Tools

Resources

KYC Status

Bug Bounty Program