Quantum Audit Logo
Launch App

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

Is 哈基米 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 · 1 audit on record
SummaryAI Copilot

The audited contract, FourERC20, is intended to be an ERC20 token.

Read the full analysis
What raised the score
  • Top-10 concentration > 20%
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Top-10 concentration > 20% (65.2% total → 27.3% effective; 2.0% in EOAs, 63.2% in contracts — mild)
  • 1 Critical finding(s) from audit
  • 1 High 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

Security Checklist

as of audit · Sep 47 of 7 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
63.2%Contracts2.0%34.8%Everyone else
63.2%Contracts34.8%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
65.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking63.2%
  • Walletsanonymous holders, free to sell2.0%
  • Everyone elsethe rest of the supply34.8%
Effective concentrationwhat the score reads27.3%
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.69M across 6 pairs
LP tokensLocked

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

Analysed pool$1.50MShare of depth88.9%
LP Burned99.9% · ≈ permanent lock
LP Locked99.9% · Null Address
Unlocked LP held by
0x2d28…e7720x48c0…ef320x0203…605f0x9cb5…708e0xc6cb…36f30x4ace…74c00xd539…bbe60xeda4…7dbd

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

Security Findings

1 Critical1 High1 Low
Critical

Missing Constructor for Token Metadata Initialization

The FourERC20 contract lacks a constructor. Consequently, the _init function, which sets the token's _name and _symbol, is never called. This results in the name() and symbol() functions returning empty strings, making the token's identity unclear and hindering its usability in applications (7.1 Architecture, 7.8 Operations).C-01

Issue

The FourERC20 contract lacks a constructor. Consequently, the _init function, which sets the token's _name and _symbol, is never called. This results in the name() and symbol() functions returning empty strings, making the token's identity unclear and hindering its usability in applications (7.1 Architecture, 7.8 Operations).

Fix

Implement a constructor in the FourERC20 contract that calls the internal _init(string memory name_, string memory symbol_) function with the desired token name and symbol. This ensures proper initialization of the token's metadata upon deployment.

Status

Unresolved

High

Absence of Token Supply Mechanism

The contract does not provide any public or constructor-based mechanism to call the internal _mint function. As a result, the _totalSupply variable will always remain zero, and no tokens can ever be created or distributed. This renders the ERC20 token completely non-functional, as no transfers or balance operations can occur (7.1 Architecture, 7.4 Economic, 7.8 Operations).H-01

Issue

The contract does not provide any public or constructor-based mechanism to call the internal _mint function. As a result, the _totalSupply variable will always remain zero, and no tokens can ever be created or distributed. This renders the ERC20 token completely non-functional, as no transfers or balance operations can occur (7.1 Architecture, 7.4 Economic, 7.8 Operations).

Fix

Introduce a mechanism to mint tokens. This could be done by calling _mint within the constructor to create an initial supply for a designated address (e.g., the deployer), or by adding an access-controlled public mint function that allows authorized entities to create new tokens.

Status

Unresolved

Low

Lack of Standard ERC20 Extensions for Operational Control

The FourERC20 contract implements the basic ERC20 standard but does not include common extensions such as Pausable functionality or Ownable/AccessControl for managing administrative roles. While not a direct vulnerability, the absence of these features means there is no emergency stop mechanism or explicit role-based access for potential future administrative actions (7.2 Code Security, 7.8 Operations).L-01

Issue

The FourERC20 contract implements the basic ERC20 standard but does not include common extensions such as Pausable functionality or Ownable/AccessControl for managing administrative roles. While not a direct vulnerability, the absence of these features means there is no emergency stop mechanism or explicit role-based access for potential future administrative actions (7.2 Code Security, 7.8 Operations).

Fix

Consider integrating OpenZeppelin's Pausable module to allow for emergency halting of transfers and Ownable or AccessControl to define and manage administrative roles. These additions enhance operational safety and provide flexibility for future governance or emergency scenarios.

Status

Unresolved

Analysis

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

The audited contract, FourERC20, is intended to be an ERC20 token. However, it lacks a constructor to initialize its name and symbol, and crucially, it has no mechanism to mint tokens. This renders the contract completely non-functional as an ERC20 token, as its total supply will always be zero. This represents a critical functional failure.

Technical7/10Low risk

The contract utilizes standard OpenZeppelin ERC20 patterns, which generally contribute to robust code security (7.2 Code Security). However, a critical architectural flaw exists where the token's name, symbol, and initial supply are never set due to the absence of a constructor or public minting function (7.1 Architecture, 7.8 Operations). This fundamental omission prevents the token from functioning as intended.

Governance8/10Low risk

The contract, as a basic ERC20 token, does not implement complex governance mechanisms (7.5 Governance). However, the complete absence of a token supply mechanism means the token has no economic function whatsoever (7.4 Economic). There are no tokens to transfer, hold, or interact with, making any economic model impossible.

Upgrades9/10Low risk

The contract is implemented directly and does not utilize any proxy patterns, meaning it is not upgradeable (7.7 Upgrades). This design choice eliminates upgrade-related risks such as proxy storage collisions or incorrect implementation logic, but also means any functional changes would require a new deployment.

Final RecommendationWhat to do about this score

To make the FourERC20 token functional, a constructor must be added to initialize the _name and _symbol state variables.

Furthermore, the constructor or a separate, access-controlled public function is required to call the _mint function, allowing for the creation of an initial token supply and subsequent minting if desired. Additionally, consider integrating standard OpenZeppelin modules like Pausable and Ownable for enhanced operational control and security.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age10mo
Contract0x82ec…4444
Deployer0x05f0…848c
Badge for your website
哈基米 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. Aug 31, 20262Low

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

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 Is this your token? Publish your own audit on this page