Quantum Audit Logo

Is 黑马 Safe?

On-chain security analysis — is it a scam or legit?

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

黑马 黑马
0xf9c6…4444
BNB Chain
Not verifiedThis record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked 9d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

The `FourERC20` contract implements a standard ERC-20 token using OpenZeppelin libraries. A critical functional issue exists where the token's name, symbol, and supply mechanism are not initialized or exposed, rendering the token unusable upon direct deployment. Further implementation is required to make this token functional.

1 Critical1 Low1 Informational
Volume 24h
$369.1K
Liquidity
$227.8K
Price
$0.0007802
Token Age
8mo
Top 10 Holders
85.7%

Security Findings

1 Crit1 Low1 Info
Critical

Missing Token Supply Mechanism and Initialization

C-01The `FourERC20` contract, as provided, is a base ERC-20 implementation that relies on internal functions `_init`, `_mint`, and `_burn`. However, there are no public or external functions within `FourERC20` itself that call `_init` to set the token's name and symbol, nor are there any mechanisms to mint or burn tokens. If this contract is deployed directly, the token will have a `totalSupply` of zero, and its `name` and `symbol` will be empty strings, rendering it completely non-functional as an ERC-20 token (7.1 Architecture, 7.8 Operations).
IssueThe `FourERC20` contract, as provided, is a base ERC-20 implementation that relies on internal functions `_init`, `_mint`, and `_burn`. However, there are no public or external functions within `FourERC20` itself that call `_init` to set the token's name and symbol, nor are there any mechanisms to mint or burn tokens. If this contract is deployed directly, the token will have a `totalSupply` of zero, and its `name` and `symbol` will be empty strings, rendering it completely non-functional as an ERC-20 token (7.1 Architecture, 7.8 Operations).
FixImplement a constructor in `FourERC20` or a derived contract that calls `_init` with desired name and symbol, and performs initial minting. Alternatively, create public/external functions in a derived contract to manage token supply (`mint`, `burn`) and ensure they are protected by appropriate access control mechanisms (e.g., `Ownable`).
StatusUnresolved
Low

Incomplete Access Control Design for Derived Contracts

L-01The `FourERC20` contract itself does not expose any functions that require access control (e.g., minting, burning). However, if a derived contract were to implement public functions that call the internal `_mint` or `_burn` functions, it would be critical to implement robust access control (e.g., using OpenZeppelin's `Ownable` or `AccessControl` modules) to prevent unauthorized manipulation of the token supply (7.3 Access Control). Without such controls, a malicious actor could potentially mint an arbitrary amount of tokens.
IssueThe `FourERC20` contract itself does not expose any functions that require access control (e.g., minting, burning). However, if a derived contract were to implement public functions that call the internal `_mint` or `_burn` functions, it would be critical to implement robust access control (e.g., using OpenZeppelin's `Ownable` or `AccessControl` modules) to prevent unauthorized manipulation of the token supply (7.3 Access Control). Without such controls, a malicious actor could potentially mint an arbitrary amount of tokens.
FixFor any derived contract that exposes token supply modification functions (like `mint` or `burn`), ensure that these functions are protected by a strong access control mechanism, allowing only authorized addresses to perform these sensitive operations.
StatusUnresolved
Info

OpenZeppelin Contracts Version

I-01The contract utilizes OpenZeppelin Contracts (last updated v4.9.4). While this version is generally considered secure, OpenZeppelin regularly releases new versions with improvements, optimizations, and potential bug fixes. The latest stable version is currently v5.x (7.2 Code Security).
IssueThe contract utilizes OpenZeppelin Contracts (last updated v4.9.4). While this version is generally considered secure, OpenZeppelin regularly releases new versions with improvements, optimizations, and potential bug fixes. The latest stable version is currently v5.x (7.2 Code Security).
FixConsider upgrading to the latest stable version of OpenZeppelin Contracts (e.g., v5.x) for new deployments to benefit from the most recent security enhancements and best practices. Ensure thorough testing if upgrading, as there might be minor breaking changes or behavioral differences.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract leverages well-audited OpenZeppelin libraries (v4.9.4) for its core ERC-20 functionality (7.2 Code Security), providing a strong foundation for standard token operations. However, a critical architectural flaw (7.1 Architecture) exists: the `_init` function for setting name/symbol and the `_mint`/`_burn` functions for supply management are internal and not called or exposed. This makes the token non-functional upon direct deployment, as it will have a zero supply and undefined metadata. There is no explicit access control (7.3 Access Control) within this base contract, which would be necessary for any derived contract implementing minting.

GovernanceLow8/10

The `FourERC20` contract is a basic ERC-20 implementation and does not include any specific economic models or governance mechanisms (7.4 Economic, 7.5 Governance). As such, there are no inherent economic or governance risks introduced by this contract itself. Any such features would need to be implemented in a derived contract.

UpgradesLow9/10

The contract is not designed with upgradeability in mind, and the provided information indicates it is not a proxy contract (7.7 Upgrades). Therefore, there are no upgrade-specific risks associated with this deployment. The `_init` pattern, while often used in upgradeable contracts, is not paired with a proxy implementation here.

Security Checklist

5/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

85.7% in top 10
5.0% in wallets80.8% in contracts
Effective Concentration37.3%

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

$236.9K across 4 pairs
Pancakeswap v2WBNBanalysed$227.8K96.2%UniswapUSDT$8.7K3.7%Pancakeswap v3USDT$3290.1%Pancakeswap v2USDT$20.0%

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

LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Key Addresses

1 addresses
Deployer
0xb261…ea61

What Raised This Score

3 factors
  • Top-10 concentration > 30% (85.7% total → 37.3% effective; 5.0% in EOAs, 80.8% in contracts — moderate)
  • 1 Critical 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
PaluLow Risk哈基米Low RiskREAL WORLD APPAREL (JACKET)Low Risk富贵Low RiskpricelessLow RiskDORALow Risk

Would You Like a More Detailed Audit of 黑马?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit