Quantum Audit Logo

Is 牛来 a Scam?

Early-stage security check — honeypot & rug-pull analysis

Is this your token? Publish your own audit on this page →

牛来 NIULAI
0x3cc3…ffff
BNB Chain Not verifiedLast checked 3d ago 1 audit on record New Launch · 2d old
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

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.

1 Critical1 High1 Medium1 Low
! Early-stage analysis. This token has limited on-chain history (2d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$40.0900
Liquidity
$24.0K
Price
$0.00005039
Token Age
2d
Top 10 Holders
30.4%

Security Findings

1 Crit1 High1 Med1 Low
Critical

Uninitialized Token State

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.
IssueThe `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.
FixAdd 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.
StatusUnresolved
High

Missing Mint/Burn Access Control

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.
IssueThe `_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.
FixIf 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.
StatusUnresolved
Medium

Redundant `unchecked` Blocks After `require` Statements

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+.
IssueSeveral 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+.
FixRemove 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+.
StatusUnresolved
Low

Standard ERC-20 `approve` Race Condition

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.
IssueThe `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.
FixWhile 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.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

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.

GovernanceHigh3/10

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

UpgradesHigh3/10

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.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom
ImplementationVerified source

Holder Composition

30.4% in top 10
4.8% in wallets25.6% in contracts
Effective Concentration15.0%

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.

Liquidity Depth

$24.0K

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0xa516…545d
Unlocked LP Held By
0xa0b7…8383

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

11 factors
  • Proxy contract (upgradeable — admin can replace logic)
  • Non-standard proxy storage (Etherscan-confirmed)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k ($24,024 across 1 pairs — thin market)
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • Token age < 7 days (early, volatile)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit

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

Related Audits

6 more on the record
XPULSHigh RiskHana Token (HANA)High RiskUpstarty (UPY)High RiskOrizon (ORI)High RiskRandyHigh RiskShopinX Token (SPX)High Risk

Would You Like a More Detailed Audit of 牛来?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit