Read the findings of the 2022 Web3 Security Report

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

Variable That Could Be Declared As Immuatable

The contract is serving as the underlying entity to interact with third-party `ILock`, `IUniswapV2Pair`, `IUniswapV2Factory`, `IUniswapV2Router` protocols. The scope of the audit treats 3rd party entities as black boxes and assumes 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

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

Missing Zero Address Validation

An arbitrary amount of the tokens can be sent to the `owner` when deploying the contract. This could be a centralization risk as the owner can distribute tokens without obtaining the consensus of the community. Since the privilege of the owner, it is possible of being maliciously manipulated by hackers if the account of the owner was compromised.

Initial Token Distribution

There is no length validation between two arrays in functions.


Missing Validation for Array Length

The function that affects the status of sensitive variables should be able to emit events as notifications.

Missing Emit Events

The variables `sellFeeRate_` ,`buyFeeRate_`,`sellBurnFeeRate_`,`buyBurnFeeRate_`,`sellLqFeeRate_`,`buyLqFeeRate_` do not have reasonable boundaries in the function `setFeeRate()` ,`setBurnFeeRate()` and `setLqFeeRate()`, so it can be changed arbitrarily after deploying.

Lack of reasonable boundary

The `owner` has the privilege to mint an arbitrary amount of tokens to any address. This function may lead to critical centralization risk.


Owner Can Mint Arbitrary Amount of Tokens

In the contract `FeeLockToken`, the role `owner` has authority over the following functions:
- function transferToken(): to transfer any ERC20 tokens in the contract to any address.
- function setLockContract(): to set the lock contract address.
- function setKeepBalance(): to enable/disable `keepBalance` status.
- function setLqWallet(): to set the Lq Wallet address, which receives the Lq fees.
- function setFeeWallet(): to set the fee Wallet address, which receives the fees in the contract.
- function setFeeRate(): to set sell fee and buy fee.
- function setBurnFeeRate(): to set the burn fee.
- function setLqFeeRate(): to set Lq fee.
- function setSwapPair(): to add the swap pair address.
- function setFeeWhiteList(): to add/remove address to/from the whitelist. 

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

Centralization Related Risks

The `for` loop in the function `multiMint()`/ `multiTransfer()` takes the unbounded array's length as the maximum iteration times. If the size of the array grows large, iterating through the entire array could be an expensive operation considering there are external calls in the `for` loop. Even worse, if the computation for each iteration is extremely complex, it could lead to gas insufficiency.

Potential Gas Exhaustion

Boolean constants can be used directly and do not need to be compared to true or false.

Comparison to Boolean Constant

The variable `deadWallet` could be declared as `constant` since this state variable is never modified.

Variable That Could Be Declared As `constant`

If the value of the variable `keepBalance` is `True`, one token per user's account remains there forever and cannot be traded.

Potential Leftover Token

Omnisphere DAO

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

10

0

4