Quantum Audit Logo
Launch App

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

Is Hana Token Safe?

HANABNB 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
Chart
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance1/10Upgrades6/10Checks passed3 of 5Findings1 High · 1 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The HanaToken contract is an ERC20 token implementing standard functionalities from OpenZeppelin, including burnable and permit extensions, with Ownable access control.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is an EOA
  • Top-10 concentration > 50%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 53.8%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 43 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
47.4%Contracts33.6%Wallets19.1%Everyone else
47.4%Contracts33.6%Wallets19.1%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
80.9%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking47.4%
  • Walletsanonymous holders, free to sell33.6%
  • Everyone elsethe rest of the supply19.1%
Effective concentrationwhat the score reads52.5%
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.12M across 5 pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$1.12MShare of depth100.0%
Top-1 Unlocked Holder53.8%
Top-3 Unlocked100.0%
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.

Security Findings

1 High1 Medium1 Low1 Info
High

Centralized Control of Token Burning

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

Issue

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

Fix

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

Status

Unresolved

Medium

Single Point of Failure for Ownership (EOA Owner)

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

Issue

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

Fix

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

Status

Unresolved

Low

Lack of Timelock for Critical Administrative Actions

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

Issue

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

Fix

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

Status

Unresolved

Info

High Solidity Compiler Version Adoption

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

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical6/10Medium risk

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

Governance1/10High risk

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

Upgrades6/10Medium risk

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

Final RecommendationWhat to do about this score

To enhance the security and decentralization of the HanaToken contract, it is recommended to transition ownership from an EOA to a robust multi-signature wallet or a well-governed DAO.

Additionally, consider implementing a timelock mechanism for critical administrative functions like transferOwnership to provide a delay for community review and reaction. Review the necessity of the onlyOwner modifier on burn functions; if not strictly required, consider removing it to decentralize burning capabilities.

Contract & Record

2 audits on record
TypeHanaToken
NetworkBNB Chain
Token age10mo
Contract0x6261…8353
Deployer0x3f24…511b
Badge for your website
Hana Token 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. Sep 4, 202666High
  2. Jul 27, 202658Medium
  3. Jul 26, 202664Medium

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

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 recordAll audits
XPULSBNB Chain66HighUpstartyUPY · BNB Chain66HighOrizonORI · BNB Chain66High牛来NIULAI · BNB Chain66HighRandyBNB Chain66HighShopinX TokenSPX · BNB Chain66High

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