Read the findings of the 2022 Web3 Security Report

Functions that affect the status of sensitive variables should be able to emit events as notifications to customers.

Missing Emit Events

It is recommended to add `indexed` keyword for parameters in events, which makes it easier for users to navigate event logs.

Address Type Could Be Indexed In Events

The assigned values to `owner`, `stakingWallet` and `marketingFeeReceiver` should be verified as non-zero values to prevent being mistakenly assigned as `address(0)` in the `setStakingFeeReceiver()`, `setMarketingFeeReceiver()` and `constructor()` functions respectively. 

Lack of Zero Address Validation

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

Redundant Code Components

`require` can be used to check for conditions and throw an exception if the condition is not met, in which case the descriptive error message provided by the developer will appear and help to track error and debugging.

Lack of Error Message

There are many hardcode addresses in this codebase.

Hardcode Address

Literals with many digits are difficult to read and review.

Too Many Digits

The contract is serving as the underlying entity to interact with third-party DEX. The scope of the audit would treat those 3rd party entities as black boxes and assume their functional correctness. However, in the real world, 3rd parties may be compromised and lead to assets being lost or stolen.

Third Party Dependencies

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

Initial Token Distribution

Comparison to A Boolean Constant

The return values of function  `addLiquidityETH` are not properly handled.
```solidity
router.addLiquidityETH{value: amountBNBLiquidity}(
                address(this),
                amountToLiquify,
                0,
                0,
                marketingFeeReceiver,
                block.timestamp
            );
```

Return Value Not Handled

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 back running (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:

- `router.swapExactTokensForETHSupportingFeeOnTransferTokens()`
- `router.addLiquidityETH()`

Potential Sandwich Attacks

The `addLiquidity()` function calls the `uniswapV2Router.addLiquidityETH` function with the `to` address specified as `marketingFeeReceiver` for acquiring the generated LP tokens from the pool. As a result, over time the `marketingFeeReceiver` address will accumulate a significant portion of LP tokens. If the `marketingFeeReceiver` is an EOA (Externally Owned Account), mishandling of its private key can have devastating consequences to the project as a whole.

Centralized risk in `addLiquidity`

The functions `setBuyFees()` and `setSellFees()` are to update fees, if `totalFee` or `feeDenominator` is set to zero, the function `_transferFrom()` will be unnecessarily reverted.

Lack of Input Validation

The `_maxTxAmount` and `_maxWalletSize` are set to certain fractions of the fixed `_totalSupply`. However, the circulating token supply is declining as fees are being deducted while the aforementioned restricting parameters remain unchanged. 

Discussion For  `_maxTxAmount` And `_maxWalletSize`

To bridge the gap in trust between the administrators need to express a sincere attitude regarding the considerations of the administrator teamʼs anonymity.

The `owner` has the responsibility to notify users about the following capabilities:
- add address' authorization through `authorize()`
- remove address' authorization through `unauthorize()`
- transfer ownership to new address through `transferOwnership()`
- set `timeF` through `updateTimeF()`
- set blacklist through `setBl()`
- set `tradingEnabled`, `swapEnabled` and `launchTimestamp` through `startTrading()`
- set `_maxWalletSize` through `setMaxWallet()`
- exclude anyone from max wallet or include anyone in max wallet through `excludeFromMaxWallet`
- exclude anyone from max tx or include anyone in max tx through `excludeFromMaxWallet`

The `authorized` has the responsibility to notify users about the following capabilities:
- set `_maxTxAmount` through `setTxLimit()`
- set `isFeeExempt` through `setIsFeeExempt()`
- set `liquidityFee`, `marketingFee`, `stakingFee`, `totalFee` and `feeDenominator` through `setBuyFees()`
- set `liquidityFee`, `marketingFee`, `sellStakingFee`, `totalSellFee` and `feeDenominator` through `setSellFees()`
- set `stakingWallet` through `setStakingFeeReceiver()`
- set `marketingFeeReceiver` through `setMarketingFeeReceiver()`
- set `swapEnabled` and `swapThreshold` through `setSwapBackSettings()`
- send bnbs to `marketingFeeReceiver` through `manualsend()`
- transfer all foreign tokens to `marketingFeeReceiver` through `transferERC20()`

Any compromise to the `owner`/`authorized` account may allow a hacker to take advantage of this authority.

Centralization Related Risks

The function `setSellFees()` sets the selling fees parameter. The `liquidityFee` and `marketingFee` are buying parameters. The correct ones should be `sellLiquidityFee` and `sellMarketingFee`.

Incorrect Selling Fees Setting

The `tempLiqProviderFee` and `launchedAt` variables are not used in the contract.

Unused Variable/Constants

All variable types within Solidity are initialized to their default "empty" value, which is usually their zeroed out representation. Particularly:

- `uint` / `int`: All `uint` and `int` variable types are initialized at `0`
- `address`: All `address` types are initialized to `address(0)`
- `byte`: All `byte` types are initialized to their `byte(0)` representation
- `bool`: All `bool` types are initialized to `false`
- `ContractType`: All contract types (i.e. for a given `contract ERC20 {}` its contract type is `ERC20`) are initialized to their zeroed out address (i.e. for a given `contract ERC20 {}` its default value is `ERC20(address(0))`)
- `struct`: All `struct` types are initialized with all their members zeroed out according to this table

Redundant Variable Initialization

The `isTxLimitExempt` limits the maximum transfer amount and `isMaxWalletExempt` limits the maximum wallet size. However, line 343 is a detection of the maximum wallet size, which is inconsistent with the detection logic in line 370.

Usage of `isTxLimitExempt`

`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.

MetaDoge

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

21

0

20

0

1