Early-stage security check — honeypot & rug-pull analysis
BNB ChainThe FourERC20 contract is a custom implementation of the ERC-20 standard.
Each factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed
Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.
Holder balances as recorded by the audit of Sep 4, 2026
The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0xa0b7…8383No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
FourERC20 contract lacks a constructor or any public initialization function to set the token's _name, _symbol, and _totalSupply. As a result, upon deployment, the token will have an empty name, empty symbol, and a total supply of zero. This renders the token completely unusable and non-functional as an ERC-20 asset.C-01The FourERC20 contract lacks a constructor or any public initialization function to set the token's _name, _symbol, and _totalSupply. As a result, upon deployment, the token will have an empty name, empty symbol, and a total supply of zero. This renders the token completely unusable and non-functional as an ERC-20 asset.
Add a constructor to the FourERC20 contract that takes name_ and symbol_ as arguments and calls _init(name_, symbol_). Additionally, if an initial supply is desired, call _mint(msg.sender, initialSupply) within the constructor to set the _totalSupply and assign tokens to the deployer.
Unresolved
_mint and _burn functions are declared as internal virtual, meaning they can only be called by the contract itself or derived contracts. However, there are no public or external functions provided in FourERC20 that call _mint or _burn. This design prevents any entity from increasing or decreasing the token's supply after deployment, making it a fixed-supply token without any initial supply, which is a critical limitation.H-01The _mint and _burn functions are declared as internal virtual, meaning they can only be called by the contract itself or derived contracts. However, there are no public or external functions provided in FourERC20 that call _mint or _burn. This design prevents any entity from increasing or decreasing the token's supply after deployment, making it a fixed-supply token without any initial supply, which is a critical limitation.
If the token is intended to have minting and burning capabilities, implement public functions (e.g., mint(address to, uint256 amount) and burn(uint256 amount)) that call the internal _mint and _burn functions. These public functions should incorporate robust access control mechanisms (e.g., onlyOwner, onlyMinter) to restrict who can perform these sensitive operations.
Unresolved
unchecked Blocks After require Statements_transfer, _burn, decreaseAllowance, and _spendAllowance, use unchecked blocks for arithmetic operations (e.g., _balances[from] = fromBalance - amount;) immediately after a require statement has already validated that the operation will not underflow (e.g., require(fromBalance >= amount)). While not a vulnerability due to the preceding require, the unchecked block is redundant and does not provide additional safety or significant gas savings in these specific contexts in Solidity 0.8+.M-01Several functions, such as _transfer, _burn, decreaseAllowance, and _spendAllowance, use unchecked blocks for arithmetic operations (e.g., _balances[from] = fromBalance - amount;) immediately after a require statement has already validated that the operation will not underflow (e.g., require(fromBalance >= amount)). While not a vulnerability due to the preceding require, the unchecked block is redundant and does not provide additional safety or significant gas savings in these specific contexts in Solidity 0.8+.
Remove the unchecked blocks where a require statement already guarantees the safety of the arithmetic operation. This improves code clarity and removes unnecessary constructs without compromising security in Solidity 0.8+.
Unresolved
approve Race Conditionapprove function, as implemented, is susceptible to a known ERC-20 front-running attack. If a user approves an amount for a spender, and then attempts to change that approval to a lower amount, a malicious spender could front-run the transaction, spend the original approved amount, and then the user's transaction would approve the lower amount, effectively allowing the spender to spend more than intended.L-01The approve function, as implemented, is susceptible to a known ERC-20 front-running attack. If a user approves an amount for a spender, and then attempts to change that approval to a lower amount, a malicious spender could front-run the transaction, spend the original approved amount, and then the user's transaction would approve the lower amount, effectively allowing the spender to spend more than intended.
While not a critical vulnerability specific to this implementation, it's a known ERC-20 limitation. To mitigate, encourage users to use increaseAllowance and decreaseAllowance instead of directly calling approve to change an existing allowance. Alternatively, a two-step approval process (approve 0, then approve new amount) can be used, though this is less user-friendly.
Unresolved
The FourERC20 contract is a custom implementation of the ERC-20 standard. A critical vulnerability exists where the token is not initialized, resulting in zero total supply, name, and symbol upon deployment. There are no public functions to mint tokens or set metadata, rendering the token completely unusable. This fundamental flaw makes the contract non-functional as an ERC-20 token.
The FourERC20 contract attempts to implement the ERC-20 standard, leveraging OpenZeppelin interfaces for compliance (7.1 Architecture). However, it suffers from a critical initialization flaw where the token's name, symbol, and total supply are never set, rendering it unusable (7.2 Code Security). Furthermore, there are no public functions to mint or burn tokens, severely limiting its intended utility (7.3 Access Control). While some arithmetic operations correctly use unchecked blocks after require statements, others are redundant.
The contract does not implement any specific governance mechanisms (7.5 Governance). However, its economic viability is critically compromised due to the lack of initialization and minting capabilities, rendering the token economically non-functional (7.4 Economic). There are no external dependencies that introduce economic risk (7.6 External).
The contract is not designed to be upgradeable, as indicated by is_proxy: false in the prefill (7.7 Upgrades). Therefore, there are no upgrade-specific risks or considerations. Any changes would require a new deployment.
Implement a constructor to properly initialize the token's name, symbol, and initial total supply using the _mint function.
If the token is intended to be mintable or burnable after deployment, add controlled public functions for these operations, typically restricted to an owner or minter role. Ensure all critical state variables are correctly set upon deployment to make the token functional.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
The 牛来 (NIULAI) contract on BNB Chain is 0x3cc3c4f12dae4908d140c342eff50cf30a56ffff. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Quantum Audit's risk score for 牛来 is 66/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Upgradeable. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $24.0K.
As of Sep 4, 2026, the 10 largest holders own 30.4% of the supply. The Holders section on this page shows who they are by holder type.
This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.
Get Detailed Audit Is this your token? Publish your own audit on this page
