<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

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

The function that affects the status of sensitive variables should be able to emit events as notifications to users.
- tradingStatus
- cooldownEnabled
- setNumTokensSellToAddToLiquidityt
- setMaxTxPercent_base1000
- setMaxTxTokens
- setMaxWalletPercent_base1000
- setMaxWalletTokens
- _setAllFees
- set_sell_multiplier
- set_All_Fees_Triggers
- set_All_Fees_Minimum_Balance

Missing Emit Events

In the contract `INVENT`, the role `owner` has authority over the following functions:
- `transferOwnership()` to transfer the ownership;
- `Change_Wallet_Marketing()` to update the `_wallet_marketing` address to an arbitrary address;
- `Change_Wallet_Buyback()` to update the `_wallet_buyback` address to an arbitrary address;
- `Change_Wallet_Burn()` to update the `_wallet_burn` address to an arbitrary address; 
- `excludeFromReward()`/`includeInReward()` to exclude/include a given account from/in reward;
- `tradingStatus()` to update the `tradingOpen` as true/false;
- `cooldownEnabled()` to enable/disable the `buyCooldownEnabled` and update the value of `cooldownTimerInterval`;
- `setNumTokensSellToAddToLiquidityt()` to update the `_numTokensSellToAddToLiquidity`;
- `setMaxTxPercent_base1000()` to update the value of `_maxTxAmount`;
- `setMaxTxTokens()` to update the value of `_maxTxAmount`;
- `setMaxWalletPercent_base1000()` to update the value of `_maxWalletToken`;
- `setMaxWalletTokens()` to update the value of `_maxWalletToken`;
- `setSwapAndLiquifyEnabled()` to enable/disable the `swapAndLiquifyEnabled`;
- `s_manageExcludeFromFee()` to exclude an array of addresses from fees;
- `s_manageBlacklist()` to blacklist an array of addresses;
- `s_manageWhitelist()` to whitelist an array of addresses;
- `s_excludeFromFee()` to exclude an array of addresses from fees;
- `convertLiquidityBalance()` to convert all stored tokens into LP Pairs;
- `purgeContractBalance()` to transfer the balance to `_wallet_marketing`;
- `fees_to_bnb_manual()` to convert any account's tokens to BNBs;
- `set_sell_multiplier()` to update the `sellMultiplier`;
- `set_All_Fees_Triggers()` to update the `_fee_marketing_convert_limit` and `_fee_buyback_convert_limit`;
- `set_All_Fees_Minimum_Balance()` to update the `_fee_buyback_min_bal` and `_fee_marketing_min_bal`;
- `set_All_Fees()` to update all of the fees;
- `burn_tokens_to_dead()` to send any account's tokens to `deadAddress`.

the role `_wallet_marketing` has authority over the following functions:
- `purgeContractBalance()` to withdraw all the BNBs from contract to market wallet.

the account `_wallet_buyback` , `_wallet_burn` and `_wallet_marketing` can receive the transfer fees.

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

Centralization Related Risks

If both sender and receiver are not excluded from fee, each transaction will be charged the following fees:
- `burn fee`, which is to dead address
- `marketing fee`, which is to marketing wallet
- `liquidity fee`, which is used to add liquidity and the LP tokens is for a centralized account
- `buyback fee`, which is to buyback wallet
- `reflection fee`, which is redistributed to all existing holders using a form of rebasing mechanism

All the fee rates and wallet can be set by owner. The total fee rates is no more than `40%` of the transfer amount. When it comes to a sell transaction, the fee rates will be changed by the `sellMultiplier`. 

Financial Models 

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 total supply amount of tokens that are minted to the centralized address, may raise the community's concerns about the centralization issue.

Token Minted To Centralized Address

The assigned values to `_wallet_marketing`,`_wallet_buyback` and `_wallet_burn` should be verified as non-zero values to prevent being mistakenly assigned as `address(0)` in the `Change_Wallet_Marketing()`, `Change_Wallet_Buyback()` and `Change_Wallet_Burn()` functions respectively.

Lack of Zero Address Validation

In function `Change_Wallet_Marketing()`, `Change_Wallet_Buyback()`, and `Change_Wallet_Burn()`, the `_isExcludedFromFee` does not exclude the newly updated `_wallet_buyback`,`_wallet_marketing` and `_wallet_burn` from fees as implemented in the constructor. 

Updating Wallet Addresses Without Updating Related Status

If the `_wallet_burn` is changed from dead address to any other normal user address, it will not be a burn wallet any more.

`_wallet_burn` should not be Changed

The function `reflectionFromToken()` uses `_getValues(tAmount,false)` to calculate the values. The hardcode input `false` used in function `_getValues()` makes this function can not calculate the reflection from token correctly when it comes to a sell transaction.

Error in Function `reflectionFromToken()`

The function `s_excludeFromFee()` is same as function `s_manageExcludeFromFee()` except the function name.

Redundant Function

In function `_fees_to_bnb_process()`, the balance of contract is updated without checking whether the `address(this)` is excluded from reward or not. If it is excluded from reward by the owner, the `_balance_total[address(this)]` should be updated.

Updating Balance of `address(this)` Mistakenly

The owner can sell tokens from anyone's wallet without approval by function `fees_to_bnb_manual()`. This may raise the community's concerns about the centralization issue.

Owner Could Sell Anyone's Token Without Approval

The owner can burn tokens from anyone's wallet to dead address without approval by function `burn_tokens_to_dead()`. This may raise the community's concerns about the centralization issue.

Owner Could Burn Anyone's Token Without Approval

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:

- `uniswapV2Router.swapExactTokensForETHSupportingFeeOnTransferTokens()`
- `uniswapV2Router.addLiquidityETH()`

Potential Sandwich Attacks

The `addLiquidity()` function calls the `uniswapV2Router.addLiquidityETH` function listed below with the `to` address specified as `0x38FEBBBD7B96e459692C9B9FE8F8cF62653277C8` for acquiring the generated LP tokens from the `INV-BNB` pool. As a result, over time this address will accumulate a significant portion of LP tokens. If this account is an EOA (Externally Owned Account), mishandling of its private key can have devastating consequences to the project as a whole.
```solidity=988
function addLiquidity(uint256 tokenAmount, uint256 ethAmount) private {
    _approve(address(this), address(uniswapV2Router), tokenAmount);
    uniswapV2Router.addLiquidityETH{value: ethAmount}(
        address(this),
        tokenAmount,
        0,
        0,
        0x38FEBBBD7B96e459692C9B9FE8F8cF62653277C8,
        block.timestamp
    );
}
```

Besides, the `to` address is hardcode as `0x38FEBBBD7B96e459692C9B9FE8F8cF62653277C8` which is the original market wallet. However, if the market wallet is updated later by the owner, this `to` address is still the original market wallet.

Centralization Risk in `addLiquidity`

The `require` at Line 1021, which is used to limit the wallet size, is calculated mistakenly. Because the transaction may be charged fees, the receiver could not receive the total amount. The `heldTokens + amount` should be `heldTokens + tTransferAmount`.

Judging Exceeding `_maxWalletToken` Mistakenly

In this contract, the total transfer fees only have the limit `less than 40% of the transfer amount`. When it comes to a sell transaction, the fees even can be near to the total amount of the transfer amount since the `sellMultiplier` has no limit. We think the transfer fee may be too high and can be limited at a lower rate.

Leaderboards

Due Diligence Tools

Resources

KYC Status