Quantum Audit Logo

Is Hachiko Inu a Scam?

Honeypot, rug-pull and ownership checks

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

Hachiko Inu HACHIKO
0xf1c5…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
Executive SummaryAI Copilot

The FourERC20 contract, intended as an ERC-20 token, exhibits critical functional flaws. It lacks a constructor to initialize essential token metadata (name, symbol) and does not expose any mechanism to mint or burn tokens, rendering it non-functional as a standalone token. Additionally, there is a complete absence of access control for any potential privileged operations. The provided code snippet is also truncated, limiting a full assessment.

1 Critical2 High1 Informational
i Our automated scanner reviewed Hachiko Inu (HACHIKO) on BNB Chain. 5 of 5 security checks passed — see the full breakdown below.
Volume 24h
$408.3K
Liquidity
$139.6K
Price
$0.001133
Age
9mo
Top 10 Holders
22.9%

Security Findings

Critical

Missing Constructor and Uninitialized Token Metadata

C-01The `FourERC20` contract lacks a constructor. The internal `_init(string memory name_, string memory symbol_)` function, which is intended to set the token's name and symbol, is never called. Consequently, `_name` and `_symbol` will remain empty strings, and `_totalSupply` will remain zero, making the token non-functional upon deployment. This impacts 7.1 Architecture and 7.8 Operations.
IssueThe `FourERC20` contract lacks a constructor. The internal `_init(string memory name_, string memory symbol_)` function, which is intended to set the token's name and symbol, is never called. Consequently, `_name` and `_symbol` will remain empty strings, and `_totalSupply` will remain zero, making the token non-functional upon deployment. This impacts 7.1 Architecture and 7.8 Operations.
FixImplement a public constructor that calls `_init` with the desired token name and symbol. For example: `constructor(string memory name_, string memory symbol_) { _init(name_, symbol_); }`.
StatusUnresolved
High

Lack of Supply Mechanism

H-01The contract includes internal `_mint` and `_burn` functions, but no public or external functions are provided to call them. This means there is no mechanism to create or destroy tokens, rendering the ERC-20 token unusable as its `_totalSupply` will always remain zero. This directly impacts 7.4 Economic and 7.1 Architecture.
IssueThe contract includes internal `_mint` and `_burn` functions, but no public or external functions are provided to call them. This means there is no mechanism to create or destroy tokens, rendering the ERC-20 token unusable as its `_totalSupply` will always remain zero. This directly impacts 7.4 Economic and 7.1 Architecture.
FixImplement public or owner-controlled functions (e.g., `mint(address to, uint256 amount)`) that call the internal `_mint` and `_burn` functions. These functions must be protected by appropriate access control mechanisms.
StatusUnresolved
High

Missing Access Control

H-02The `FourERC20` contract does not implement any access control mechanisms (e.g., `Ownable`, `AccessControl`). If privileged functions (such as minting, burning, or pausing) were to be added, they would be callable by any external address, leading to severe security vulnerabilities and potential loss of control over the token supply. This impacts 7.3 Access Control and 7.5 Governance.
IssueThe `FourERC20` contract does not implement any access control mechanisms (e.g., `Ownable`, `AccessControl`). If privileged functions (such as minting, burning, or pausing) were to be added, they would be callable by any external address, leading to severe security vulnerabilities and potential loss of control over the token supply. This impacts 7.3 Access Control and 7.5 Governance.
FixIntegrate a robust access control mechanism, such as OpenZeppelin's `Ownable` or `AccessControl` contracts. All functions intended for privileged users (e.g., future minting functions) must be protected with appropriate modifiers (e.g., `onlyOwner`).
StatusUnresolved
Info

Truncated Code Snippet

I-01The provided source code for `FourERC20.sol` is truncated, specifically the `_transfer` function and potentially other parts of the contract. This limits the scope of the audit and prevents a complete security assessment of the entire codebase. This impacts 7.2 Code Security.
IssueThe provided source code for `FourERC20.sol` is truncated, specifically the `_transfer` function and potentially other parts of the contract. This limits the scope of the audit and prevents a complete security assessment of the entire codebase. This impacts 7.2 Code Security.
FixProvide the complete and untruncated source code for all contracts to enable a comprehensive security audit.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract utilizes OpenZeppelin's `Context` for standard utilities, which generally contributes to robust code security (7.2 Code Security). However, a critical architectural flaw (7.1 Architecture) is the absence of a constructor, leaving `_name` and `_symbol` uninitialized. Furthermore, the internal `_mint` and `_burn` functions are not exposed, preventing any token supply management. There is a complete lack of access control (7.3 Access Control) for any privileged functions, which would be a severe vulnerability if minting capabilities were added without it.

GovernanceLow7/10

The economic model (7.4 Economic) is severely impacted by the lack of a supply mechanism; the token cannot be created or destroyed, rendering it economically inert. There are no governance mechanisms (7.5 Governance) implemented, meaning no on-chain decision-making processes are available for the token. Without proper access control, any future additions of supply management would pose a high economic risk due to potential uncontrolled minting.

UpgradesLow9/10

The contract is not designed as an upgradeable proxy (7.7 Upgrades), as indicated by `is_proxy: false`. Therefore, upgrade safety is not a concern, and the contract's logic is immutable once deployed.

Security Checklist

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

Holder Composition

9.6% in wallets13.3% in contracts
Effective Concentration15.0%

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

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

Deployer
0x9a26…2f52
Unlocked LP Held By
0x8e3c…5d530x8416…673d0x0b47…028a0x0ed9…97060x57fe…cd610x2a31…209f

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

What Raised This Score

  • 1 Critical finding(s) from audit
  • 2 High 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

BroccoliLow RiskMomentum (MNTM)Low RiskBanana For Scale (BANANAS31)Low Risk翻身币税助力凉兮翻身 (翻身币)Low RiskWorld of Dypians (WOD)Low RiskTagger (TAG)Low Risk

Would You Like a More Detailed Audit of Hachiko Inu?

Paste the contract address into our AI-powered scanner for a deeper real-time report — free, with every scoring factor shown.

Get Detailed Audit