Quantum Audit Logo

Is Hana Token Safe?

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

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

Hana Token HANA
0x6261…8353
BNB Chain Not verifiedLast checked 3d ago 2 audits on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The HanaToken contract is an ERC20 token implementing standard functionalities from OpenZeppelin, including burnable and permit extensions, with Ownable access control. The contract exhibits good code quality and leverages battle-tested libraries. Key findings include centralized control over token burning, the use of an EOA for ownership, and the absence of a timelock for critical administrative actions. These issues introduce centralization risks and potential single points of failure.

1 High1 Medium1 Low1 Informational
Volume 24h
$546.5K
Liquidity
$1.12M
Price
$0.01977
Token Age
10mo
Top 10 Holders
80.9%

Security Findings

1 High1 Med1 Low1 Info
High

Centralized Control of Token Burning

H-01The `burn` and `burnFrom` functions in the `HanaToken` contract are restricted to the `onlyOwner` modifier. This grants the contract owner exclusive power to reduce the total supply of tokens. Such centralization introduces a significant risk, as a compromised owner key or a malicious owner could unilaterally impact the token's supply dynamics, potentially leading to adverse economic consequences or a loss of trust from token holders (7.3 Access Control, 7.4 Economic).
IssueThe `burn` and `burnFrom` functions in the `HanaToken` contract are restricted to the `onlyOwner` modifier. This grants the contract owner exclusive power to reduce the total supply of tokens. Such centralization introduces a significant risk, as a compromised owner key or a malicious owner could unilaterally impact the token's supply dynamics, potentially leading to adverse economic consequences or a loss of trust from token holders (7.3 Access Control, 7.4 Economic).
FixEvaluate whether the burning functionality truly requires `onlyOwner` restriction. If not, consider removing the `onlyOwner` modifier to allow any token holder to burn their own tokens, or implement a more decentralized burning mechanism. If centralized burning is a design choice, ensure the owner's address is secured by a robust multi-signature wallet or a DAO.
StatusUnresolved
Medium

Single Point of Failure for Ownership (EOA Owner)

M-01The contract's ownership is held by an Externally Owned Account (EOA), as indicated by the provided data (`owner_kind: EOA`). This creates a single point of failure. If the EOA's private key is compromised, lost, or becomes inaccessible, critical administrative functions such as `burn`, `burnFrom`, and `transferOwnership` would be at risk of unauthorized use or permanent inaccessibility, impacting the contract's long-term operational integrity (7.3 Access Control, 7.8 Operations).
IssueThe contract's ownership is held by an Externally Owned Account (EOA), as indicated by the provided data (`owner_kind: EOA`). This creates a single point of failure. If the EOA's private key is compromised, lost, or becomes inaccessible, critical administrative functions such as `burn`, `burnFrom`, and `transferOwnership` would be at risk of unauthorized use or permanent inaccessibility, impacting the contract's long-term operational integrity (7.3 Access Control, 7.8 Operations).
FixIt is strongly recommended to transfer ownership of the contract to a multi-signature wallet (e.g., Gnosis Safe) or a decentralized autonomous organization (DAO) controlled by a robust governance mechanism. This distributes control and significantly reduces the risk associated with a single point of failure.
StatusUnresolved
Low

Lack of Timelock for Critical Administrative Actions

L-01The `transferOwnership` function allows the current owner to immediately transfer ownership to a new address. Without a timelock mechanism, a malicious or accidental transfer of ownership cannot be reversed or prevented by the community or other stakeholders. This lack of a delay increases the risk of immediate and irreversible control loss, especially if the owner's key is compromised (7.3 Access Control, 7.5 Governance).
IssueThe `transferOwnership` function allows the current owner to immediately transfer ownership to a new address. Without a timelock mechanism, a malicious or accidental transfer of ownership cannot be reversed or prevented by the community or other stakeholders. This lack of a delay increases the risk of immediate and irreversible control loss, especially if the owner's key is compromised (7.3 Access Control, 7.5 Governance).
FixConsider implementing a timelock mechanism for critical administrative functions, particularly `transferOwnership`. This would introduce a mandatory delay between initiating an ownership transfer and its execution, providing a window for detection and potential intervention in case of an erroneous or malicious action.
StatusUnresolved
Info

High Solidity Compiler Version Adoption

I-01The contract uses `pragma solidity ^0.8.28`. While newer compiler versions often include optimizations and bug fixes, very recent versions might have less extensive real-world testing and community scrutiny compared to more established and widely adopted versions (e.g., `0.8.19` or `0.8.20`). This is a minor informational point, as OpenZeppelin contracts are generally well-tested across supported compiler versions (7.2 Code Security).
IssueThe contract uses `pragma solidity ^0.8.28`. While newer compiler versions often include optimizations and bug fixes, very recent versions might have less extensive real-world testing and community scrutiny compared to more established and widely adopted versions (e.g., `0.8.19` or `0.8.20`). This is a minor informational point, as OpenZeppelin contracts are generally well-tested across supported compiler versions (7.2 Code Security).
FixWhile not a direct vulnerability, projects should be aware of the trade-offs when adopting the absolute latest compiler versions. Ensure that all dependencies and tools are fully compatible and that sufficient testing is conducted. For production deployments, sometimes a slightly older, more battle-tested compiler version within the `0.8.x` range is preferred for maximum stability.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract leverages battle-tested OpenZeppelin libraries for ERC20, Burnable, Permit, and Ownable functionalities, contributing to robust code security and adherence to standards. It utilizes a recent Solidity compiler version (`^0.8.28`), benefiting from the latest language features and optimizations. However, the `burn` and `burnFrom` functions are restricted to the `onlyOwner` modifier, centralizing the power to reduce token supply. Furthermore, the contract owner is an EOA, presenting a single point of failure for critical administrative access (7.3 Access Control, 7.2 Code Security).

GovernanceHigh1/10

The token's economic model is straightforward, with a fixed `INITIAL_SUPPLY` minted once, preventing inflationary risks from further minting. However, the centralized control over token burning, where only the owner can execute `burn` or `burnFrom`, introduces a significant governance risk as a single entity can impact the total supply. The current EOA ownership also poses an economic risk due to the single point of failure for critical operations (7.4 Economic, 7.5 Governance).

UpgradesMedium6/10

The HanaToken contract is not designed with upgradeability patterns (e.g., proxy contracts), meaning its logic cannot be modified post-deployment. This eliminates risks associated with upgrade mechanisms, such as proxy implementation vulnerabilities or improper upgrade paths. However, any future feature enhancements or bug fixes would require a new contract deployment and token migration (7.7 Upgrades).

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

80.9% in top 10
33.6% in wallets47.4% in contracts
Effective Concentration52.5%

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.12M across 5 pairs
Pancakeswap v3USDTanalysed$1.12M100.0%Pancakeswap v3WBNB$360.0%Pancakeswap v2Subject 3$40.0%Pancakeswap v2WBNB$10.0%Pancakeswap v2DPJF$00.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

Top-1 Unlocked Holder53.8%
Top-3 Unlocked100.0%

Key Addresses

3 addresses
Deployer
0x3f24…511b
Unlocked LP Held By
0x5d92…02050x3410…7391

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

What Raised This Score

8 factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Top-10 concentration > 50% (80.9% total → 52.5% effective; 33.6% in EOAs, 47.4% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 53.8% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 1 High finding(s) from audit
  • 1 Medium 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

Frequently Asked Questions

Is Hana Token a scam?

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

Is Hana Token safe to buy?

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

Has Hana Token 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.

Related Audits

6 more on the record
XPULSHigh RiskUpstarty (UPY)High RiskOrizon (ORI)High Risk牛来 (NIULAI)High RiskRandyHigh RiskShopinX Token (SPX)High Risk

Would You Like a More Detailed Audit of Hana Token?

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

Get Detailed Audit