Quantum Audit Logo
Launch App

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

Is 4 Safe?

BNB Chain
Not verified This 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 Sep 4, 2026 · 2 audits on record
SummaryAI Copilot

The FourERC20 contract is an OpenZeppelin-based ERC-20 implementation.

Read the full analysis
What raised the score
  • Top-10 concentration > 30%
  • 1 Critical finding(s) from audit
Exact factors
  • Top-10 concentration > 30% (63.0% total → 34.9% effective; 16.1% in EOAs, 46.9% in contracts — moderate)
  • 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

Security Checklist

as of audit · Sep 45 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
46.9%Contracts16.1%Wallets37.0%Everyone else
46.9%Contracts16.1%Wallets37.0%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
63.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking46.9%
  • Walletsanonymous holders, free to sell16.1%
  • Everyone elsethe rest of the supply37.0%
Effective concentrationwhat the score reads34.9%
How holder types affect the score

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

Liquidity

as of audit · Sep 4$1.43M across 16 pairs
LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$1.29MShare of depth90.1%
LP Burned99.9% · ≈ permanent lock
LP Locked99.9%
Unlocked LP held by
0x5b8d…6ef20xdfff…a08b0x33eb…bf5b0x286b…87260x6662…c1550x40f3…0fe70x5604…8c260xed1d…751f0xd36b…6deb

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

Security Findings

1 Critical1 Info
Critical

Incomplete ERC-20 Implementation (Non-Functional Token)

The FourERC20 contract, as provided, lacks a public constructor to initialize the token's name and symbol via _init. More critically, it does not expose any public or external function to call the internal _mint function. If this contract is deployed directly, it will result in an ERC-20 token with no name, no symbol, and a permanent zero total supply, rendering it completely non-functional and unusable. This represents a fundamental architectural flaw for a standalone token (7.1 Architecture, 7.4 Economic).C-01

Issue

The FourERC20 contract, as provided, lacks a public constructor to initialize the token's name and symbol via _init. More critically, it does not expose any public or external function to call the internal _mint function. If this contract is deployed directly, it will result in an ERC-20 token with no name, no symbol, and a permanent zero total supply, rendering it completely non-functional and unusable. This represents a fundamental architectural flaw for a standalone token (7.1 Architecture, 7.4 Economic).

Fix

A new contract should be created that inherits from FourERC20. This derived contract must include a public constructor that calls _init(string memory name_, string memory symbol_) to set the token's metadata. Additionally, it must implement a public or access-controlled function (e.g., mint or initialMint) that calls the internal _mint(address account, uint256 amount) to create the initial token supply and distribute it.

Status

Unresolved

Info

Contract Designed for Inheritance, Not Direct Deployment

The FourERC20 contract is structured as a base OpenZeppelin ERC20 implementation, providing internal functions like _init, _mint, and _burn. This design pattern is common for creating extensible token standards. It is intended to be inherited by a derived contract that would then implement specific constructor logic and supply mechanisms (7.1 Architecture). This is not a vulnerability in itself, but a misunderstanding of this design leads directly to the critical issue of a non-functional token if deployed incorrectly.I-01

Issue

The FourERC20 contract is structured as a base OpenZeppelin ERC20 implementation, providing internal functions like _init, _mint, and _burn. This design pattern is common for creating extensible token standards. It is intended to be inherited by a derived contract that would then implement specific constructor logic and supply mechanisms (7.1 Architecture). This is not a vulnerability in itself, but a misunderstanding of this design leads directly to the critical issue of a non-functional token if deployed incorrectly.

Fix

Ensure that any deployment strategy for FourERC20 involves creating a derived contract that properly extends its functionality, specifically by implementing a constructor and a token supply mechanism. Document this design intent clearly for future developers and deployers.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The FourERC20 contract is an OpenZeppelin-based ERC-20 implementation. While it utilizes well-audited components, it is designed as a base contract for inheritance rather than direct deployment. If deployed as-is, it lacks a public constructor to initialize token metadata (name, symbol) and, critically, a mechanism to mint tokens, rendering it non-functional with a zero total supply. This architectural flaw presents a critical risk to its intended utility.

Technical8/10Low risk

The contract leverages well-audited OpenZeppelin ERC-20 standards, providing robust implementations for core token functionalities like transfers and allowances (7.2 Code Security). The use of increaseAllowance and decreaseAllowance mitigates common allowance front-running risks. However, the contract lacks a public constructor to initialize token metadata and a public minting mechanism, making it non-functional if deployed directly (7.1 Architecture). This design oversight prevents token creation and renders the contract unusable as a standalone ERC-20 token.

Governance8/10Low risk

The economic model is inherently flawed if the contract is deployed as-is, as no tokens can be minted, leading to a zero total supply (7.4 Economic). This directly impacts the utility and value proposition of the token, rendering it economically inert. There are no specific governance mechanisms implemented within this contract (7.5 Governance), which is typical for a base ERC-20, but the lack of a functional supply mechanism is a critical economic impediment.

Upgrades9/10Low risk

The contract does not implement any proxy patterns or upgrade mechanisms (7.7 Upgrades). This means the contract is immutable once deployed, preventing any future modifications to its logic. While this eliminates upgrade-related risks such as proxy misconfigurations or malicious upgrade paths, it also means any discovered issues or desired feature enhancements would require a new deployment.

Final RecommendationWhat to do about this score

It is crucial to understand that the FourERC20 contract is a foundational ERC-20 implementation intended for inheritance.

For a functional token, a derived contract must be created that includes a constructor to call _init with desired name and symbol, and implements a public or controlled mechanism to call _mint to create the initial token supply. Deploying this contract directly without these additions will result in a non-functional token.

Contract & Record

2 audits on record
TypeToken
NetworkBNB Chain
Token age9mo
Contract0x0a43…4444
Deployer0x5511…7f3d
Badge for your website
4 security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Jul 27, 20260Low
  2. Jul 27, 202667High

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Frequently Asked Questions

Is 4 a scam?

Based on automated analysis, 4 scores 67/100 (High Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.

Is 4 safe to buy?

Our scanner flagged a risk score of 67/100. Ownership has not been renounced, which is a risk factor. DYOR before purchasing any token.

Has 4 been audited?

The contract has not been verified on-chain. Verification is not the same as a full security audit. Use Quantum Audit's free tool to run a deeper analysis of the contract code.

Would You Like a More Detailed Audit of 4?

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

Get Detailed Audit Is this your token? Publish your own audit on this page