Is 哈基米 Safe? Smart Contract Security Analysis

Security Findings

1 Crit1 High1 Low

Critical

Missing Constructor for Token Metadata Initialization

C-01The `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).

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

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

StatusUnresolved

High

Absence of Token Supply Mechanism

H-01The 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).

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

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

StatusUnresolved

Low

Lack of Standard ERC20 Extensions for Operational Control

L-01The `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).

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

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

StatusUnresolved

Category Ratings

TechnicalLow7/10

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.

GovernanceLow8/10

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.

UpgradesLow9/10

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.

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

65.2% in top 10

2.0% in wallets63.2% in contracts

Effective Concentration27.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

$1.69M across 6 pairs

Pancakeswap v2WBNBanalysed$1.50M Pancakeswap v3USDT$94.5K UniswapUSDT$81.7K Pancakeswap v3WBNB$11.9K Pancakeswap v2USDT$7 Pancakeswap v2BUSD$1

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 Burned99.9% · ≈ permanent lock

LP Locked99.9% · Null Address

Key Addresses

9 addresses

Deployer

0x05f0…848c

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.

What Raised This Score

4 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

Is 哈基米 Safe?

Security Findings

Missing Constructor for Token Metadata Initialization

Absence of Token Supply Mechanism

Lack of Standard ERC20 Extensions for Operational Control

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of 哈基米?