Quantum Audit Logo

Is Dust Safe?

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

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

Dust DUST
0x932f…4444
BNB Chain Not verifiedLast checked today 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

The FourERC20 contract is an ERC-20 token implementation based on OpenZeppelin. A critical architectural flaw prevents the token from being initialized or having any supply, rendering it unusable. The contract lacks a constructor, meaning its name, symbol, and initial supply cannot be set, resulting in a permanent zero total supply.

1 Critical2 Informational
Volume 24h
$404.5K
Liquidity
$126.0K
Price
$0.0002596
Token Age
11mo
Top 10 Holders
43.2%

Security Findings

1 Crit2 Info
Critical

Missing Constructor and Unmintable Token

C-01The `FourERC20` contract, which inherits from `Context` and implements `IERC20`, lacks a constructor. The internal `_init` function, responsible for setting the token's `_name` and `_symbol`, is never called. More critically, the `_totalSupply` remains at its default value of zero, and since the internal `_mint` function is not exposed or called by any public function, no tokens can ever be created. This renders the token completely non-functional and unusable, as it will always have a zero supply and no identifiable name or symbol. (7.1 Architecture, 7.2 Code Security, 7.4 Economic)
IssueThe `FourERC20` contract, which inherits from `Context` and implements `IERC20`, lacks a constructor. The internal `_init` function, responsible for setting the token's `_name` and `_symbol`, is never called. More critically, the `_totalSupply` remains at its default value of zero, and since the internal `_mint` function is not exposed or called by any public function, no tokens can ever be created. This renders the token completely non-functional and unusable, as it will always have a zero supply and no identifiable name or symbol. (7.1 Architecture, 7.2 Code Security, 7.4 Economic)
FixA constructor must be added to the `FourERC20` contract (or its derived contract) that calls `_init(string memory name_, string memory symbol_)` to set the token's metadata. Additionally, the constructor or a controlled public function should call `_mint(address account, uint256 amount)` to establish an initial token supply.
StatusUnresolved
Info

Base ERC-20 Implementation Lacks Public Minting/Burning

I-01The `FourERC20` contract provides the core ERC-20 logic but keeps the `_mint` and `_burn` functions internal. This design implies that `FourERC20` is intended as a base contract for inheritance, where a derived contract would implement specific supply mechanisms (e.g., a fixed supply, minter role, pauser role). As a standalone contract, it lacks the ability to create or destroy tokens after deployment (assuming a constructor would handle initial minting). (7.1 Architecture)
IssueThe `FourERC20` contract provides the core ERC-20 logic but keeps the `_mint` and `_burn` functions internal. This design implies that `FourERC20` is intended as a base contract for inheritance, where a derived contract would implement specific supply mechanisms (e.g., a fixed supply, minter role, pauser role). As a standalone contract, it lacks the ability to create or destroy tokens after deployment (assuming a constructor would handle initial minting). (7.1 Architecture)
FixIf this contract is intended to be a standalone, deployable token, consider adding public or role-based functions to manage token supply (e.g., `mint(address to, uint256 amount)` with an `onlyOwner` or `onlyMinter` modifier). If it's strictly a base, ensure the derived contract correctly implements supply management.
StatusUnresolved
Info

`_init` Function Usage

I-02The `_init` function is designed to set the `_name` and `_symbol` of the token. Being an `internal` function, it must be explicitly called by a constructor of the contract itself or a derived contract. If not called, `_name` and `_symbol` will remain empty strings, which is not standard for an ERC-20 token and can cause issues with interfaces displaying token information. (7.1 Architecture)
IssueThe `_init` function is designed to set the `_name` and `_symbol` of the token. Being an `internal` function, it must be explicitly called by a constructor of the contract itself or a derived contract. If not called, `_name` and `_symbol` will remain empty strings, which is not standard for an ERC-20 token and can cause issues with interfaces displaying token information. (7.1 Architecture)
FixEnsure that any contract inheriting `FourERC20` or `FourERC20` itself, includes a constructor that calls `_init` with appropriate `name_` and `symbol_` parameters.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract is a basic ERC-20 implementation leveraging OpenZeppelin's `Context` library. It correctly implements standard ERC-20 functions and includes mitigations for allowance race conditions (7.2 Code Security). However, a critical architectural oversight means the contract lacks a constructor, preventing the `_init` function from being called and any tokens from ever being minted (7.1 Architecture). This renders the token completely non-functional.

GovernanceLow9/10

The economic model is severely impacted by the critical technical flaw (7.4 Economic). With no constructor to initialize `_name`, `_symbol`, or mint an initial supply, the token will have a permanent `totalSupply` of zero. This makes the token economically worthless and unusable. There are no governance mechanisms present (7.5 Governance).

UpgradesLow9/10

The contract is not designed to be upgradeable (7.7 Upgrades). This simplifies its architecture by avoiding proxy-related complexities and potential upgrade safety issues.

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

43.2% in top 10
10.2% in wallets33.0% in contracts
Effective Concentration23.4%

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

$126.2K across 4 pairs
Pancakeswap v2WBNBanalysed$126.0K99.8%Pancakeswap v3WBNB$2430.2%Pancakeswap v2Subject 3$110.0%Pancakeswap v2USDT$40.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 Burned98.7% · ≈ permanent lock
LP Locked98.7%

Key Addresses

10 addresses
Deployer
0xfe80…02da
Unlocked LP Held By
0x0ed9…97060x9cfc…e62b0xafea…b6560x0a90…2bb20x22fe…a1750x4e89…e2750x556a…1b0b0x8d58…123f0x0819…928f

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

What Raised This Score

2 factors
  • Top-10 concentration > 20% (43.2% total → 23.4% effective; 10.2% in EOAs, 33.0% in contracts — mild)
  • 1 Critical 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
TCryptochicks (TCC)Low Risk币安人生Low RiskSKYAILow RiskBLow RiskDOYRLow RiskCREPELow Risk

Would You Like a More Detailed Audit of Dust?

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

Get Detailed Audit